composer why-not 是最准确的冲突诊断命令，它从目标包出发逆向追踪完整依赖链，逐层显示版本约束与冲突点；composer prohibits 已弃用且不显示层级关系；配合 composer show -t 可辅助验证依赖树。
composer why-not 能看到冲突的完整依赖链
直接用 composer why-not 是最准的方式，它会从你当前想安装/升级的包出发，逆向追踪所有阻止它被安装的依赖约束，逐层列出每个中间包的版本要求和冲突点。比如你想装 monolog/monolog:^3.0 但失败了，运行：
composer why-not monolog/monolog:^3.0
输出里会清晰显示类似：your-project → some-package:1.2 → psr/log:^1.0 → 冲突 monolog/monolog:^3.0（因为 psr/log:^1.0 不兼容 monolog/monolog:^3.0 要求的 psr/log:^2.0）。
composer prohibits 是旧版命令，已弃用且不显示层级
composer prohibits 在 Composer 2.0+ 中已被移除，即使在旧版中它也只返回“谁依赖了这个包”，不体现版本约束关系或嵌套路径。强行用会报错 Command "prohibits" is not defined，或者只列出一级依赖，无法定位深层冲突。别再查文档里过时的用法了。
用 composer show -t 查看当前依赖树辅助验证
当 why-not 输出太长、难以聚焦时，先运行：
composer show -t
快速浏览整个依赖树，重点关注报错中提到的中间包（比如 some-package），确认它的实际安装版本是否卡在旧版。常见陷阱包括：
- 项目
composer.json中对某个包写了硬性版本锁（如"some-package": "1.2"），导致下游无法升级 - 某个 dev-only 包（如
phpunit/phpunit）间接拉入了冲突的 psr/log 版本，而它本不该影响生产依赖 - 使用了
replace或provide的包伪造了接口兼容性，但实际行为不一致
冲突常出在 psr/log、symfony/polyfill、phpunit 等跨项目基础包上
这些包被大量库依赖，且不同主版本间存在语义化版本断裂（如 psr/log:^1.0 和 psr/log:^2.0 不兼容）。排查时优先检查它们：
- 运行
composer show psr/log看当前装的是哪个版本 - 搜项目中所有
composer.json（包括 vendor 下的）里对psr/log的 require 约束 - 注意
symfony/polyfill-php*包有时会暗中 require 旧版psr/log，尤其在 PHP 7.x 项目中
层级深不代表问题复杂，往往就是某一个包的版本锁没松开，或者该删掉的 require-dev 还留在那里。
