Composer依赖树查看：告别版本猜谜，锁定真实依赖

想看清项目依赖的真实全貌？别再折腾那些不稳定的插件或参数了。当前最可靠、无需额外配置的方案，就是直接使用 composer show -t。记住，是短横线 -t，不是那个命运多舛的 --tree。这个命令的厉害之处在于，它直接读取 vendor/ 目录和 composer.lock 文件构成的真实快照，展示的正是已经安装到项目里的依赖关系，而不是你写在 composer.json 里的那份“愿望清单”。

为什么 composer show --tree 总是不工作？

遇到命令报错或者没反应，先别怀疑自己的记忆力。这事儿真不怪你，根源在于 --tree 这个参数在 Composer 不同版本里上演了一出“反复横跳”的戏码。它最初在 2.2.0 版本被引入，随后在一些 2.2.x 的小版本中又被移除，直到 2.5.0 版本之后被彻底放弃。所以，现在如果你看到“Unrecognized option: --tree”的错误，或者命令静默执行却没有任何输出，大概率就是撞上了这个版本兼容性问题。

验证方法很简单：运行 composer --version 看一眼版本号。如果版本低于 2.2.0，先运行 composer self-update 升级一下；如果已经是 2.5.0 或更高版本，那就彻底忘掉 --tree，果断切换到 -t 吧。

• composer show -t 是当前唯一被稳定支持的短参数，其作用完全等同于旧版 --tree 的意图。
• 如果不加任何包名，它会输出整个项目的依赖树，动辄几百行，看着都眼晕。建议指定具体目标包，例如：composer show -t guzzlehttp/guzzle。
• 当终端宽度不够时，缩进可能会被截断，影响查看。这时可以加上管道命令：composer show -t --no-dev | less -S，就能横向滚动浏览了。

使用 composer show -t 查不到包？先确认这三件事

命令返回“Package not found”或者一片空白？别急着断定命令失效，90%的情况是环境还没准备好。

• 首先，vendor/ 目录必须存在且非空——如果从来没运行过 composer install 或 composer update，依赖根本就没安装，自然查不到。
• 其次，composer.lock 文件得有内容，它是 Composer 解析依赖后生成的精确快照，没有它就无法还原依赖关系。
• 最后，包名必须精确无误：大小写、斜杠、供应商名一个都不能错。比如 monolog/monolog，写成 Monolog/monolog 或者光秃秃的 monolog 都是不行的。

还有一个常被忽略的细节：如果目标包只存在于 require-dev 开发依赖中，而你执行命令时又加上了 --no-dev 参数，那它当然不会出现。

想反向查询“谁在依赖某个包”？别用 depends，试试 composer show --who

composer depends 命令其实是个实验性功能（在 2.4+ 版本默认关闭），而且当遇到 provide、replace 或者本地 path 仓库时，判断容易出纰漏。相比之下，composer show --who 就干脆利落得多，它直接扫描所有已安装包的 require 字段，结果干净又确定。

• 查询谁显式依赖了 psr/log：composer show --who psr/log
• 如果想排除开发依赖：composer show --who --no-dev psr/log
• 需要注意的是，它只显示“直接声明依赖者”。举个例子，如果依赖链是 A → B → C，那么对 C 执行 --who 命令，只会列出 B；想看到根源 A，需要配合 composer show -t B 向上追溯。

如果 --who 返回了空结果，也不代表绝对没人用。有可能是某个包通过 "provide": {"psr/log": "*"} 的方式虚拟提供了这个包，实际实现藏在别处。遇到这种情况，就得回头用 composer show -t 把全局依赖树扫一遍了。

依赖树里看到了旧版本？别慌，那是冲突妥协的结果

有时候会发现一个奇怪的现象：明明在 composer.json 里写着 "guzzlehttp/guzzle": "^7.0"，但 composer show -t 显示的却是 v6.5.8。这通常不是 bug，而是因为项目里其他已安装的包强制要求 v6 版本，Composer 在解决依赖冲突时自动进行了降级，并将这个妥协后的结果锁进了 composer.lock。

• 务必记住，composer show -t 展示的是“最终落地版本”，而不是“你期望的版本”。
• 要定位到底是哪个包在卡版本，可以立刻补查：composer why guzzlehttp/guzzle 查看第一层冲突来源，如果想继续向上溯源，可以再加上 --tree 参数。
• 如果溯源结果的结尾带有 [dev] 标记，说明冲突来自某个 require-dev 开发依赖。在上线生产环境前，记得用 --no-dev 参数重新安装验证。

真正让人头疼的，其实不是树形结构本身，而是依赖树在某一层突然中断。比如，查看到 lara vel/framework 这一层就没了下文。这大概率是因为它使用了 provide 声明了某个虚拟包，而实际的实现被隐藏在了另一个包里。这时候，show -t 就无能为力了，只能靠 grep 命令扫描 composer.lock 文件，或者手动去翻源码了。