Composer怎么查询包的依赖关系_Composer depends命令用法【实用】

在PHP开发中，Composer的依赖管理堪称艺术，但有时也像一团迷雾。当你需要理清一个包为何出现在项目中，或者评估引入新包的潜在影响时，选对命令至关重要。一个常见的误区是，开发者们总想找一个“万能”命令来解决所有依赖查询问题，结果往往在几个看似相似但行为迥异的命令间迷失方向。

这里先给个核心结论，帮你拨开迷雾：查看已安装包的完整依赖树，唯一稳定可靠的选择是 composer show --tree；而想查明“谁”依赖了某个特定包，则应优先使用 composer why --tree 或 composer show --who。至于那个听起来很直接的 composer depends，它其实是个默认关闭的实验性功能，不仅容易漏判，日常使用中坑也不少，建议绕道而行。

为什么 composer depends 经常查不到东西？

这个命令从Composer 2.4版本才被引入，而且默认处于禁用状态。你必须先手动开启它：
composer config experimental.show-depends true
否则，直接运行类似 composer depends monolog/monolog 的命令，要么会报错，要么就静默地什么都不输出，让人一头雾水。

即便你开启了实验开关，这个命令也存在几个硬伤，让它难以胜任日常排查工作：

• 当遇到包声明了 provide（例如某个包声明 "psr/log": "*"）时，它不会将这个提供者算作“依赖方”。
• 对于使用了 replace 或本地 path 类型仓库的包，它的识别能力基本失灵。
• 对于仅在 require-dev 中声明但尚未实际安装到 vendor/ 目录的包，它会直接当作不存在。

说白了，composer depends 查的仅仅是“明确声明了直接require”的包。但Composer自身在解析依赖时，必须处理虚拟包（provide）和包替换（replace）这些复杂逻辑。这个命令却选择性地忽略了这些现实，给出的结果自然是不完整的，甚至具有误导性。

composer why --tree：溯源依赖真相的关键

如果你想搞清楚 monolog/monolog 这个包为什么会出现在你的项目里，光用 composer why monolog/monolog 可能不够。默认情况下，它可能只告诉你直接依赖者是 lara vel/framework。但你真正需要确认的是：这个依赖的源头是不是你自己在项目的 composer.json 文件里亲手写下的？

这时候，必须加上 --tree 选项：

• 运行 composer why --tree monolog/monolog，如果输出结果的末尾出现了 your-project-name dev-main，那就意味着源头是你自己的项目。
• 如果末尾带有 [dev] 标记，则说明它来自 require-dev 部分的依赖。
• 有时依赖树在某一层就中断了（比如停在了 symfony/console 就不再向下展开），这通常是正常的。这可能是因为上层的包通过 provide 声明了某个接口，而实际实现包（如 psr/log）被“虚拟”提供了，因此依赖链在此处被视为满足，不再继续追溯。

记住，不加 --tree 选项，你看到的只是依赖链中的一环，相当于只看了半张地图，无法窥见全貌。

composer show --who：干净直接地查找“声明者”

如果你想快速知道当前已安装的包里，有哪些在自己的 composer.json 里直接写了 require "psr/log"，那么 composer show --who 是你的好帮手：

• composer show --who psr/log：这会列出所有直接require它的包，包括开发依赖（require-dev）。
• composer show --who --no-dev psr/log：加上 --no-dev 选项，可以排除开发依赖，只关注运行时的依赖链路。

需要注意的是，--who 选项的设计哲学是只显示“直接声明者”。例如，依赖链是 A → B → C，那么查询C时，它只显示B，不会显示A。这不是缺陷，而是其设计目标：它回答的问题是“谁的文件里写了这行require”，而不是“谁最终在运行时加载了它”。

如果查询结果为空，先别急着断定这个包没用并删除它。更稳妥的做法是运行 composer show --tree | grep psr/log，查看这个包在全局依赖树中的位置。很可能，它是被某个包通过 provide 机制间接提供的。

未安装的包也能查：使用 --remote 选项进行评估

在决定是否安装一个新包（比如 doctrine/orm）之前，你可能会担心它拖进来一大堆陈旧的依赖项。其实，你不需要先require再remove来试探。

• composer show --remote --tree doctrine/orm：这个命令可以查看该包在远程仓库（如Packagist）中声明的完整依赖树。
• composer show --remote --direct doctrine/orm：如果只想看它自己 composer.json 里第一层的 require 列表，用这个命令。

这类操作纯粹是读取Packagist的API信息，完全不会触碰本地的 vendor/ 目录和 composer.lock 文件，既安全又轻量。不过，有一点必须警惕：远程信息不包含版本冲突判断。你看到的依赖树是基于包声明的理想情况，实际安装时，可能会因为与你现有包的版本约束不兼容而导致安装失败或版本回退。

最后，一个容易被忽略的前提是：上述所有命令的有效执行，都依赖于当前目录下存在一个有效的 composer.json 文件。对于需要分析已安装依赖的命令（如 --tree），还需要有效的 composer.lock 文件；对于查询远程信息的命令（--remote），则需要网络畅通。缺少任何一个条件，命令的输出都不可信。在开始任何依赖梳理之前，先确认好这些基础环境，往往能事半功倍。