Composer卡在Resolving dependencies是SAT求解器暴力穷举版本组合导致的指数级计算爆炸，非网络或配置错误；应通过--no-plugins --no-scripts -v排除干扰，用composer why-not定位冲突源头，并以composer update pkg --with-dependencies精准收敛求解范围。
Composer在大型项目中卡死在Resolving dependencies，不是网络问题，也不是配置写错了，而是SAT求解器正在暴力穷举所有版本组合——当依赖图里有30+包、含conflict、replace或跨大版本约束时，求解空间会指数爆炸。
为什么composer update卡住超过5分钟？
这不是“慢”，是求解失败前的无效尝试。日志里反复出现Trying: vendor/package:v1.2.3、Backtracking，说明Composer正回溯上万种组合，试图满足所有require和conflict约束。
-
composer install --no-plugins --no-scripts -v先排除插件干扰，确认是否纯解析瓶颈 - 临时删掉
composer.lock再跑composer update --dry-run -v，看是否陷入无限回溯——如果是，说明锁文件固化了一个脆弱解 - 重点关注输出末尾反复出现的
requires和conflicts行，它们大概率是递归链上的死结
用composer why-not精准定位阻断链
composer why-not不是问“为什么不能装”，而是问“当前状态为何不允许共存”。它直接切开多层嵌套依赖，暴露真实冲突源头。
- 比如你想装
monolog/monolog:3.0.0，但失败了，就运行：composer why-not monolog/monolog:3.0.0 - 输出里每一行都是一个阻断点：可能是
laravel/framework的require，也可能是your-project根composer.json里的conflict规则 - 如果输出第一行是
your-project，说明你自己的约束写死了——别只盯着第三方包改
避免全量更新，用--with-dependencies收敛搜索范围
在大型项目里执行composer update等于让求解器重跑整个NP难问题。真正可控的做法是锁定路径，只动必要部分。
- 想升级
guzzlehttp/guzzle？别update全部，改用：composer update guzzlehttp/guzzle --with-dependencies - 如果连带升级太多，进一步缩小范围：
composer update vendorA/pkgA vendorB/pkgB --with-dependencies - 升级后立刻检查
git diff composer.lock，重点看source.reference字段变化——commit hash变动才代表代码真变了，版本号微调可能只是元数据刷新
replace不是绕过校验，是主动接管依赖决策
"replace": {"old/package": "*"}不会卸载old/package，而是告诉求解器：“当其他包require old/package时，视为已满足，不用再找兼容版本”。但它不解决运行时类加载冲突。
- 若你fork了
symfony/console并重命名为myorg/console，必须确保autoload规则覆盖原命名空间，否则Class not found照常发生 -
replace对conflict字段无效——被替换包声明的"conflict": {"php": ">=8.0"}，你的替换包仍需自行声明兼容性 - 慎用
provide模拟扩展：如用symfony/polyfill-mbstring替代ext-mbstring，必须确认项目没用到该扩展的C级特性（如mb_ereg）
最常被忽略的点是autoload越界：require-dev里的包如果被src/下的生产代码直接引用，Composer就会把它当作硬依赖纳入求解图——检查autoload和autoload-dev的命名空间是否严格隔离。
