composer 的 solver 不是外部 sat 求解器，而是基于 php 自研的 cdcl 风格回溯式 csp 求解器，将包版本建模为布尔变量、约束转为逻辑子句，但不生成标准 cnf 也不调用 minisat/z3。
Composer 的 Solver 不是调用外部 SAT 求解器，也不是暴力试错，而是自研的、带冲突驱动学习（CDCL 风格）的回溯式约束求解引擎——它在数学上逼近 SAT 问题，但实现上完全基于 PHP，专为 Packagist 生态优化。
Composer 的 Solver 到底是不是 SAT 求解器？
不是外部 SAT 求解器，但建模思想高度借鉴 SAT：每个 vendor/package:1.2.3 被视为一个布尔变量（选中为 true），require、conflict、replace、provide 全部转为逻辑子句。但它不生成标准 CNF 公式，也不调用 MiniSat/Z3；真实执行者是 BacktrackingSolver 类中的 tryToSolve() 和 backtrack() 方法。
常见误解来源：早期文档用 “SAT solver” 是类比其目标（找一组满足所有约束的版本赋值），而非描述技术实现。Composer 2.0+ 的求解器本质是 CSP（约束满足问题）求解器，融合了：
- 深度优先搜索（DFS）主干
- 单元传播（unit propagation）剪枝
- 冲突驱动回退 + 简化版子句学习（跳过已证伪的组合）
composer update 卡在 “Resolving dependencies…” 是什么在运行？
这是 BacktrackingSolver 正在做全局一致性推演：它要同时满足你根项目的 composer.json、所有间接依赖的 require、每个包声明的 conflict，甚至 replace 和 provide 关系。这不是卡住，是正在穷举可行路径。
容易踩的坑包括：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 手动改了
composer.json却没删composer.lock：Solver会以 lock 为起点做“最小变更”，反而锁死本可解的路径 -
config.platform.php与实际环境脱节，导致大量合法版本被提前排除 - 混用稳定性标记，比如同时 require
"monolog/monolog": "dev-main"和"phpunit/phpunit": "^9.6"（后者要求 stable） - 某包在多个路径中反复展开（如
a → b → a），触发隐式循环依赖，引发无限回溯
为什么 composer install 几乎秒出结果？
因为 composer install 完全不运行 Solver。它只校验当前 composer.lock 是否仍满足 composer.json 的约束——这个文件不是缓存，而是上一次 Solver 成功输出的「已验证可行解」，含完整版本号、SHA256 校验和、安装路径及依赖映射。
这意味着：
- 删掉
composer.lock后直接composer install会失败（无解可验） -
composer.lock被篡改后，install可能跳过校验（取决于--no-scripts或--ignore-platform-reqs）但结果不可信 - CI 环境中应始终提交
composer.lock，否则每次构建都变成一次全新求解，极易因元数据波动失败
如何定位 Solver 报错的真正根源？
Your requirements could not be resolved to an installable set of packages 不是随机失败，是 Solver 已数学证明无解。它输出的冲突链（如 “root requires A, but B requires C”）是最短可解释矛盾路径，不是全部依赖图。
实操建议：
- 加
-v查最后尝试的包链：composer update -v | tail -30 - 局部更新更可控：
composer update --with-dependencies my/package - 临时清 lock 再试（仅限开发）：
rm composer.lock && composer update - 用
composer show -t --no-dev --ignore-platform-reqs观察真实安装上下文下的依赖树，人工扫描重复出现的包名组合（强循环信号）
最常被忽略的一点：Solver 的决策不是“谁该让步”，而是按确定性策略推进——根 composer.json 中的 require 具有最高固定性，所有回溯都围绕它们收紧或替换，而非随意降级。
