Composer show –tree –all 显示所有包的完整依赖树【工具】

composer show –tree –all 不可靠，因为它基于 vendor/composer/installed.json 快照而非实时解析 composer.json 和 lock 文件，混杂 dev-only、残留包、replace/conflict 失效项及未裁剪的平台配置分支。

composer show --tree --all 确实能显示所有已安装包的完整依赖树，但它在实际使用中容易产生误导——它不区分“直接依赖”和“间接依赖”，也不过滤 dev-only 包，更不会反映当前 composer.json 的真实约束关系。

为什么 composer show --tree --all 显示的树看起来很全，却不可靠

这个命令会递归展开每一个已安装包（包括 require-dev 中的包），甚至包含被 replace 或 conflict 排除但因历史安装残留仍存在于 vendor/ 的包。它读取的是 vendor/composer/installed.json 的快照，而非实时解析 composer.json + lock 文件的依赖图。

• 若某包被 conflict 声明但尚未卸载，它仍会出现在树中
• --all 会强制显示所有版本分支（如 dev-main、1.x-dev），干扰对稳定依赖的判断
• 无法体现平台配置（如 platform.php）导致的版本裁剪

想看真正生效的依赖路径？用 composer depends 和 composer show --tree 组合

要定位某个包为何被装上，或验证某依赖是否真的被项目直接引用，优先用 composer depends；要看精简、可读的运行时依赖树，去掉 --all，只用 composer show --tree：

• composer depends monolog/monolog 查谁拉入了 monolog（含 transitive 路径）
• composer show --tree vendor/package 只展开指定包的子树，避免全量爆炸
• 搭配 COMPOSER_MEMORY_LIMIT=-1 防止大项目报 Allowed memory size exhausted

替代方案：用 composer why-not 和 composer prohibits 定位冲突根源

当依赖树里出现意外版本或缺失包，--tree --all 只是现象，不是原因。真正有用的是诊断命令：

• composer why-not phpunit/phpunit:10.0 显示阻止升级的具体约束（来自哪个 require / platform / conflict）
• composer prohibits guzzlehttp/guzzle ^7.0 列出所有与该版本冲突的已安装包及其原因
• 这些命令直读 composer.lock 和约束表达式，结果比 --tree --all 的静态快照更可信

依赖树不是越全越好，而是越贴近 lock 文件解析逻辑越准。别让 --all 给你一种“全都看见了”的错觉——它展示的是 vendor 目录的现状，不是 Composer 解析器的实际决策路径。