composer why 报错包不存在，主因是包名不精确匹配，需用 composer show 查完整 vendor/name 名称，开发依赖加 --dev，不支持模糊匹配；composer why-not 仅模拟单包安装冲突，不回溯依赖链。
composer why 报错说包不存在？先确认包名是否精确匹配
很多情况下 composer why 找不到依赖，不是命令失效，而是你输的包名和实际安装的不一致——比如大小写、带不带 -dev 后缀、或者用了别名（如 monolog/monolog 和 monolog 在某些旧版本里会被当作不同包）。
- 运行
composer show查看已安装包的**完整准确名称**（注意 vendor/name 格式） - 如果目标是开发依赖，加
--dev参数：composer why --dev phpunit/phpunit - 不支持通配符或模糊匹配，
composer why monolog会失败，必须写全monolog/monolog - 某些包被 require 但未启用（比如通过
replace或provide声明），why也查不到，得看composer show -t
为什么 composer why-not 不显示冲突原因？它只检查单个包的安装可行性
composer why-not 的作用很窄：它模拟「如果现在 require 这个包，会卡在哪」，但不会回溯整个依赖图。它可能只告诉你 foo/bar 要求 php: ^8.2，而你本地是 8.1，却不会指出是谁锁死了 PHP 版本（比如 symfony/flex 的某个旧版间接要求 php: ）。
- 它不分析已有依赖之间的约束交叉，只做「单点插入推演」
- 输出中出现
root requires，说明是composer.json顶层配置直接挡住了，不是依赖冲突 - 想定位深层冲突，得配合
composer depends --tree或composer show --tree看依赖链 - 如果
why-not返回空，不代表能装成功——可能是版本约束太松，但后续安装时因其他包冲突失败
composer prohibits 怎么用？它是 why 的反向视角
当某个包死活装不上，又看不出谁在拦着，composer prohibits 就是更直接的工具：它列出「当前项目里哪些包明确禁止了你想要的版本」。
- 语法是
composer prohibits vendor/package:version，比如composer prohibits guzzlehttp/guzzle:7.9.0 - 它比
why更适合排查「为什么我指定的版本被跳过」，尤其是当你手动改过composer.json的 version constraint - 注意：它查的是
conflict字段和硬性版本约束（如"guzzlehttp/guzzle": "），不查软性建议（<code>replaces或provides） - 输出里如果出现
root，说明是你自己的composer.json写了冲突规则，不是第三方包的问题
依赖冲突真正难解的地方：require-dev 和 autoload 的隐式耦合
最常被忽略的冲突源头不在 require，而在 require-dev 和自动加载配置。比如一个测试工具强制拉入某个旧版 sebastian/exporter，而它又和主应用用的 phpunit 版本不兼容；或者 autoload-dev 里注册了某个类路径，导致 Composer 自动把 dev 包当成运行时依赖处理。
- 临时排除 dev 依赖排查：加
--no-dev参数再跑composer why，看问题是否消失 - 检查
autoload和autoload-dev是否有重叠命名空间，引发类加载优先级混乱 -
composer update --dry-run比install更早暴露冲突，但它的提示有时藏在几十行日志里，得盯紧Conclusion:开头的那句 - 真实项目里，
composer.lock的 hash 错位、git merge 冲突残留、甚至 IDE 自动生成的vendor/autoload.php缓存，都可能让why显示过期结果
