根本原因是版本约束不可满足，如 package-a 要求 monolog:^2.0 而 package-b 锁定 monolog:1.26.1；用 composer update --dry-run -v 查冲突路径，composer why-not 定位阻止包，require-dev 也参与解析。
为什么 composer install 会卡在依赖解析阶段？
根本原因不是“包太多”，而是 Composer 在构建依赖树时发现多个包对同一依赖提出了互斥的版本要求。比如 package-a 要求 monolog/monolog:^2.0，而 package-b 锁定在 monolog/monolog:1.26.1，Composer 就无法找到一个同时满足两者的安装方案。
这种冲突常被误认为是“递归依赖”，其实 Composer 本身不禁止递归（如 A → B → A 是允许的），真正阻止安装的是**版本约束不可满足**。
- 运行
composer update --dry-run -v可看到详细冲突路径，比install更早暴露问题 -
composer why-not vendor/package:version能定位哪个包在阻止该版本被安装 - 注意
require-dev中的包也可能参与解析，即使你只跑install
如何用 composer show --tree 快速定位冲突源头？
composer show --tree 输出的是当前 lock 文件中已解析成功的依赖结构，它不反映冲突，但能帮你验证“某个包实际被哪个上游拉入”。真正排查冲突要先让 Composer 失败，再用诊断命令。
- 先删掉
vendor/和composer.lock，再运行composer update --dry-run，观察报错里出现的第一个冲突包 - 对那个包执行
composer depends --tree vendor/package，看哪些顶层依赖间接引入了它 - 若输出为空，说明该包未被任何已启用依赖引用——很可能是
require-dev或已废弃的配置残留
composer update 时指定包名反而加剧冲突？
执行 composer update vendor/package 并不会“只更新这个包”，而是以它为根重新计算整个依赖子图，可能激活原本被压制的旧约束。尤其当该包有宽松版本范围（如 ^1.0 || ^2.0）时，Composer 可能回退到更老、兼容性更差的版本。
- 优先用
composer update --with-dependencies vendor/package，强制连带更新其直接依赖 - 避免单独更新 dev-only 包（如
phpunit/phpunit），它们常带高版本 PHP 要求，与主项目冲突 - 如果必须锁定某包版本，写死在
require里（如"monolog/monolog": "2.9.1"），而不是靠update命令临时干预
常见陷阱：conflict 和 replace 字段被忽略
有些包在 composer.json 中声明了 "conflict": {"laravel/framework": " 或 "replace": {"symfony/console": "*"}，这些信息默认不参与冲突检测，除非你显式启用。
- 加
--ignore-platform-reqs会跳过 PHP/扩展检查，但不会绕过conflict规则 -
replace的作用是“声明本包已提供某功能”，若两个包都replace同一包（如都声称替代psr/log），Composer 会拒绝共存 - 检查第三方包的
composer.json源码，比依赖树更早发现隐性冲突点
composer prohibits monolog/monolog:1.26.1 # 输出类似： # package-a 2.1.0 requires monolog/monolog (^2.0) # package-b 3.4.2 requires monolog/monolog (1.26.1) # ...
依赖树不是图论作业，是现实约束的投影。最耗时间的往往不是找哪个包冲突，而是确认哪个包的 composer.json 里写了过时的 require 或漏写了 conflict。每次遇到奇怪的“无法解析”，先查最近更新的包的元数据，比反复 dump-autoload 有用得多。
