如何排查Composer依赖解析中的死循环问题？

本文共计1004个文字，预计阅读时间需要5分钟。

Composer解析死循环并非‘慢’，而是求解器在无限回溯——CPU持续95%、内存每秒涨50MB、composer update --dry-run -v，最后几行反复出现同一组包名，基本可以确定是闭环卡死了。

看 composer update --dry-run -v 的“临终遗言”

这个命令不改任何文件，但完整走一遍 SAT 求解流程，失败前会打印它最后尝试的组合和立即 reject 的原因。这不是日志，是求解器的决策痕迹。

• 重点盯最后 5–10 行：如果反复出现 vendor/a → vendor/b → vendor/a 这类嵌套，就是强循环信号
• 留意 “Rejecting vendor/b because it requires vendor/a ^2.0” 这类语句——而当前项目锁的是 vendor/a:1.9，说明版本约束在闭环里互相拉扯
• 如果某包名连续出现 ≥3 次（比如 myorg/core 被 myorg/api、myorg/utils、phpunit/phpunit 分别引入），大概率是间接环

用 composer depends --tree 实锤闭环链

这是目前唯一能直接看到闭环路径的命令，但有两个硬前提：项目必须已有有效的 composer.lock，且必须加 --tree 参数。