必须加 -v 才能看到真正原因：不加时仅提示“无法解析”，加后可逐行查看 because 嵌套链（如 PHP 版本、扩展或 conflict 冲突），关键信息全在输出末尾。
composer update --dry-run -v 必须加 -v 才能看到真正原因
不加 -v 的 composer update --dry-run 只会告诉你“无法解析”，但不会说为什么。冲突真正卡在哪儿，全藏在 because 嵌套链里——比如某包要求 php ^8.0，而你本地是 8.1.0，但这个信息只在详细日志里出现。
常见错误现象：
- 改了
composer.json里的版本号，composer update vendor/package却报错，提示和改之前一样 -
composer show vendor/package显示的版本和composer.lock里记录的不一致
实操建议：
- 先执行
composer update --lock同步锁文件，否则show和update看的都不是同一套约束 - 再跑
composer update --dry-run -v，从输出末尾往前翻，逐行找because开头的缩进行，它会像链条一样一层层指出谁在阻断安装 - 注意看括号里的 PHP 版本、扩展依赖（如
ext-curl）、甚至conflict字段声明的互斥包
composer show -t vendor/package 要带包名才能看到真实来源
composer show -t 不带参数时只显示顶层依赖，对排查间接冲突几乎没用。真正有用的是指定包名，它会暴露出这个包到底被谁拉进来、用了哪个版本、约束来自哪一行 composer.json。
使用场景：
- 你手动升级了
guzzlehttp/guzzle，但项目里另一个包仍坚持用v6，导致冲突 -
symfony/console出现两个版本，不知道是laravel/framework还是phpunit/phpunit在坚持旧版
实操建议：
- 运行
composer show -t guzzlehttp/guzzle，重点看每行末尾的 by xxx[version]，例如：└─guzzlehttp/guzzle[7.8.1] <strong>by laravel/framework[10.48.5]</strong> - 如果同一个包被多个父包拉入且版本范围无交集（比如一个要
^7.0，另一个要^6.5），就说明它们之间根本没法共存 - 注意：该命令反映的是当前
composer.json约束下的理论解，不是composer.lock实际锁定的版本；若刚合并过分支，务必先composer update --lock
composer why vendor/package 能快速定位“谁在偷偷依赖它”
有时候你根本没在 composer.json 里写某个包，但它就是被装进来了，还引发冲突。composer why 就是专治这种“幽灵依赖”的命令，它直接告诉你哪个已安装的包把你不需要的依赖带了进来。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
参数差异：
-
composer why psr/log：列出所有直接依赖psr/log的包（比如monolog/monolog） -
composer why --tree psr/log：显示完整依赖路径，比如my/project → monolog/monolog → psr/log
实操建议：
- 当发现某个子依赖（如
symfony/polyfill-php81）引发 PHP 版本冲突，先用composer why symfony/polyfill-php81查源头 - 如果输出为空，说明它可能通过
replace或provide被其他包“假装提供”，这时要去对应包的composer.json查"provide"字段 - 配合
composer validate检查composer.json是否有语法错误或缺失字段，否则why可能返回不完整结果
git diff composer.lock 是唯一可信的变更快照
别信 composer update 输出的“更新了 X 个包”，也别靠肉眼比对 composer.lock 文件。真正的变更只有 Git 差异能说清——尤其是当你在 CI 上看到冲突，而本地 composer install 却成功时。
性能 / 兼容性影响：
- 手动编辑
composer.lock极易破坏哈希校验，导致composer install失败或跳过某些包 - 不同 Composer 版本生成的
lock文件结构略有差异（如 v1 vs v2 的content-hash计算方式），混用可能引发静默降级
实操建议：
- 先运行
git diff composer.lock --name-only，快速确认哪些包的锁记录变了 - 再用
git diff composer.lock看具体版本变动，重点关注packages和packages-dev下的version和source字段 - 如果发现某个包的
version没变但source的reference改了，说明它可能从 tag 切到了 dev 分支，稳定性风险陡增
最常被忽略的一点：Composer 解析依赖时，composer.json 中的 minimum-stability 和 prefer-stable 会全局影响所有包的可选版本范围，哪怕你只改了一个包的版本号，也可能因稳定级别变化导致整个依赖树重排。调试时务必检查这两项是否无意中松动了约束。
