Composer install卡住是因循环依赖导致求解器无限回溯，典型表现为CPU飙升、内存增长、无响应；需用composer show -t --no-dev --ignore-platform-reqs排查，或composer-require-checker --with-dependencies定位环，最终以composer.lock为准确认依赖关系。
composer install 时卡住不动，大概率是循环依赖触发了递归死锁
Composer 本身不报错也不退出，只是 CPU 占用飙升、内存持续增长、终端无响应——这是典型的依赖图中存在 package-a → package-b → package-a 类型的强循环引用。它不会抛出 "circular dependency" 错误，因为 Composer 的依赖解析器（Solver）在构建约束图时陷入无限回溯。
真正的问题不是“找不到包”，而是求解器在尝试满足所有 require 约束时，反复切换两个包的版本组合却始终无法收敛。
- 常见诱因：
package-arequirepackage-b:^2.0，而package-b的composer.json中又 requirepackage-a:dev-main或package-a:^1.5（且该版本范围与a的约束重叠） - 注意：软循环（如通过
require-dev引入，且未启用--no-dev）也可能触发，尤其在 CI 中使用composer install --no-interaction时更难察觉 - Composer 2.2+ 默认启用 SAT 求解器，比旧版回溯更快暴露死锁，但依然不打印循环路径
用 composer show -t 查依赖树，但得加 --no-dev 和 --ignore-platform-reqs 才能逼近真实安装路径
composer show -t 是唯一内置的轻量级依赖图观察工具，但它默认包含 require-dev 和跳过平台检查，容易掩盖真实冲突点。死锁往往藏在“生产环境实际会加载的子图”里。
执行以下命令才能模拟 composer install 的真实解析上下文：
composer show -t --no-dev --ignore-platform-reqs
然后人工扫描输出中反复出现的包名组合，比如看到：
├── vendor/a/package-a v1.3.0
│ └── vendor/b/package-b ^2.1
└── vendor/b/package-b v2.1.0
└── vendor/a/package-a ^1.2
这就是强循环信号。注意：如果某包被多次展开（如 package-a 在树中出现 3 次以上），且每次引入路径都不同，也值得怀疑。
- 别信
composer validate：它只校验 JSON 格式和字段合法性，完全不检查依赖逻辑 -
composer depends <package></package>只查直接上游，对间接循环无效 - Windows 下 cmd 可能截断长树输出，建议用 PowerShell 或加
| more
用 composer-require-checker 配合自定义规则临时检测循环引用
composer-require-checker 本意是查未声明的运行时依赖，但它的图分析能力可被“借用”：当开启 --with-dependencies 并禁用自动 autoload 探测后，它会构建一个简化依赖图，并在遇到环时直接 panic 报错。
步骤如下：
- 安装：
composer global require maglnet/composer-require-checker
- 生成最小配置
require-checker.json，关掉所有非图分析功能：{ "autoload-directories": [], "autoload-files": [], "scan-all-dependencies": true, "ignore-autoload-errors": true, "extra-extensions": [] } - 运行：
composer-require-checker --config-file=require-checker.json --with-dependencies
若存在循环，你会看到类似错误：Uncaught Exception: Circular dependency detected between "a/package-a" and "b/package-b"。这是目前最接近“开箱即用”的循环定位方式。
注意：它不支持 Composer 2 的插件式依赖解析器，所以对使用 composer-plugin-api 动态修改依赖的项目无效。
手动拆解 composer.lock 的 requires 字段是最终确认手段
当所有工具都沉默，composer.lock 就是最权威的证据源。它记录了 Solver 实际选中的每个包及其 requires 列表，不含任何推测。
打开 composer.lock，搜索目标可疑包（如 "name": "a/package-a"），找到其 requires 块；再顺藤摸瓜查被 require 的包是否反过来 require 它。
- 重点看
requires中的版本约束字符串，不是 installed version：例如"a/package-a": "^1.2"比"a/package-a": "1.3.0"更危险，因为它允许 Solver 后续回退到其他版本继续试探 - 如果发现 A require B，B require C，C require A，那就是三元环——比二元环更难人工识别，必须逐层翻 lock 文件
- 不要直接删
vendor/或composer.lock来“试试看”：这会让 Solver 从头开始，可能卡在另一个环上，浪费时间
循环依赖的本质不是语法错误，而是约束系统无解。最稳妥的做法，是让其中一个包把对方的依赖降级为 require-dev 或彻底移除，哪怕要改一两行代码——毕竟自动工具只能帮你定位，不能替你做架构决策。
