composer依赖解析本质是sat求解，将所有约束转化为布尔逻辑子句并建模为cnf公式；冲突驱动回溯（cdcl）机制通过学习冲突原因剪枝搜索空间，确保数学上无解时准确报错而非重试。
Composer依赖解析本质是SAT求解，不是“试装”
Composer不按顺序下载包再检查冲突，而是把composer.json里所有require、conflict、provide、PHP平台限制，连同每个间接依赖的约束，全部翻译成布尔逻辑子句。每个vendor/package:2.1.0就是一个布尔变量，“安装它”为真，“不装”为假。整个问题被建模为一个隐式CNF公式——求解器的任务是判断是否存在一组真值赋值，让所有子句同时为真。
这意味着：Your requirements could not be resolved不是临时失败，是数学上已证明无解；composer install快，是因为它完全跳过这个过程，只读composer.lock里存好的可行解。
BacktrackingSolver的回溯不是随机重试，而是冲突驱动
Composer 2+ 的真实执行者是BacktrackingSolver类，核心逻辑在tryToSolve()和backtrack()。它不会盲目换版本，而是在每次冲突（比如两个包都要求guzzlehttp/guzzle但互斥）时记录“冲突原因”，并基于该原因剪掉整片搜索分支。这种CDCL（冲突驱动子句学习）机制能避免重复踩同一坑。
常见诱因包括：
-
monolog/monolog:2.9.0被锁死，但某依赖要求^3.0，另一依赖要求^2.8，求解器得来回验证兼容路径 - 多个包对同一包声明宽泛
conflict（如"conflict": {"ext-curl": "），导致传播链断裂 -
^2.0被拆成几十个具体版本点参与搜索，而非当区间处理；叠加~2.5.0等窄范围后，剪枝效率骤降
回溯次数无法直接配置，但可被以下操作显著抑制
Composer没提供--max-backtracks这类开关，但实际回溯深度由约束密度和版本碎片度决定。控制它的有效方式是减少搜索空间维度：
- 把
"monolog/monolog": "*"收紧为"^2.9"或"^3.5"，避免引入历史废弃小版本 - 删掉
composer.lock后运行composer update --dry-run -v，观察最后几行是否反复出现Rejecting vendor/a because it requires vendor/b ^2.0——这是回溯卡死的明确信号 - 大型更新前加
--no-dev，尤其当你没真正在CI里跑测试时；require-dev里的工具常通过autoload反向拉入你的代码，构成隐式循环 - 检查
composer.json中autoload-dev是否误写了vendor/路径，否则Composer会认为“我依赖我自己”
闭环依赖会让回溯无限进行，必须用depends --tree实锤
当CPU持续95%+、内存每秒涨50MB+，且composer update --dry-run -v末尾反复出现myorg/core → myorg/api → myorg/core这类嵌套，基本就是闭环卡死了。这不是慢，是求解器在无限回溯。
composer depends myorg/core --tree是唯一能直接看到闭环路径的命令，但有两个硬前提：
- 项目必须已有有效的
composer.lock - 必须加
--tree参数，否则composer depends只查一级上游，漏掉A→C→B→A这种多跳环
最易被忽略的闭环来源是autoload + require-dev：比如phpunit/phpunit的"autoload": {"psr-4": {"App\": "../src/"}}，会让它的运行时加载你的src/，从而把你的包反向纳入求解图。
