Composer依赖链排查：从“它依赖谁”到“谁用了它”的完整指南
在PHP项目里管理依赖，有时候就像理清一团毛线——你知道所有线头都在vendor/目录里，但具体哪条线连着哪个钩子，光看composer.json可不够。尤其是当版本冲突、依赖替换（replace）或虚拟包（provide）出现时，仅凭声明文件很难看清全貌。
这时候，你需要的是能穿透表象、直接查看实际安装依赖关系的工具。下面这张图直观展示了Composer依赖链的排查思路，我们可以对照着来理解：
核心命令就一个：composer show --tree。请务必记住，别去试composer tree或composer depends——前者是旧版插件遗留下来的无效命令，后者默认关闭且行为飘忽不定，容易误导。
查某个包的完整依赖链（正向：它依赖谁）
想搞清楚guzzlehttp/guzzle这个包到底把哪些“子依赖”带进了你的项目？包括那些层层嵌套、间接引入的包，运行这条命令就能一目了然：
composer show --tree guzzlehttp/guzzle
这里有几个关键细节需要注意：
- 命令必须在项目根目录执行，并且确保
vendor/目录已经存在（也就是说，至少成功运行过一次composer install）。 - 如果不指定包名，命令会输出整个项目的依赖树，动辄几百行，信息过载反而让人无从下手。加上包名才能精准聚焦。
- 输出结果中的“requires”字段，显示的是该包在
composer.json里声明的版本约束（比如^2.0），而不是实际安装的版本。想知道真正装的是哪个版本，得看下一层缩进显示的包名和具体版本号。 - 即使某个包是以
dev-main分支或特定提交哈希（如#a1b2c3d）的形式安装的，--tree命令依然能显示其依赖链。不过，部分间接依赖可能会因为版本解析问题而显示不全。
查谁在依赖某个包（反向：谁用了它）
反过来，如果你想弄明白monolog/monolog这个日志库，到底是被你的项目直接引用的，还是被lara vel/framework这样的上层依赖“夹带”进来的，就该用这个命令：
composer why --tree monolog/monolog
这里有个重要区别：
- 推荐使用
composer why而非composer depends。因为后者需要手动开启实验性配置（experimental.show-depends），而且对provide（虚拟包）或path（本地路径）类型的仓库支持不佳。 --tree参数至关重要。不加它，命令可能只返回直接依赖层（比如只告诉你lara vel/framework依赖它）；加上之后，才能一路追溯到最顶层的源头，确认是不是你自己的项目（your-project-name dev-main）直接要求的。- 如果输出结果末尾标记了
[dev]，说明这个依赖来自require-dev开发环境。如果依赖链在某一层突然中断（比如只显示到symfony/console就没了），那很可能是因为中断处的包通过provide声明了某个虚拟接口（如psr/log），Composer便不再继续向下解析了。
常见报错和对应解法
执行命令时如果遇到不识别或没输出的情况，先别慌，按顺序核对以下几点：
- 报错
Command "show" is not defined→ 说明你的Composer版本低于2.0。升级一下：composer self-update。 - 报错
Could not find package→ 首先检查包名是否拼写正确（必须是全小写的vendor/name格式，斜杠不能少）。其次，确认这个包确实已经安装到了vendor/目录里（比如，它可能只写在require-dev里，但你当前没有安装开发依赖）。 composer show --tree输出空白或卡住 → 大概率是vendor/目录为空，或者composer.lock文件缺失。先运行composer install安装依赖再说。- 想查看一个尚未安装的包在Packagist上声明的依赖关系？可以加上
--remote参数，例如composer show --tree lara vel/framework --remote。但请注意，这反映的只是Packagist仓库里的约束声明，不保证在你的本地环境一定能安装成功。
说到底，真正的复杂性在于：Composer的依赖解析是动态的、结果导向的。composer show --tree展示的，是基于当前vendor/目录和composer.lock文件生成的“快照”，而不是composer.json里写的那个理想化的依赖声明。
一旦项目里出现了replace（包替换）、provide（虚拟包）、path（本地仓库）或者版本冲突，依赖树的结构就可能出现跳层或中断。这时候，最稳妥的做法是结合composer why --tree和单独查看某个包详情的composer show 命令，交叉验证输出结果，而不是只相信其中一条命令告诉你的“故事”。
