Composer如何查看当前的依赖树视图

正确用法是直接运行composer show --tree，需在含composer.json的项目根目录执行；该命令基于vendor和composer.lock显示已安装依赖的真实树状结构，漏写--tree或版本低于2.0均会导致失败。

composer show --tree 显示依赖树的正确用法

想看清项目依赖的完整脉络？其实很简单，直接在命令行敲入 composer show --tree 就行了。这是 Composer 自带的功能，不需要额外安装任何插件。

新手最容易犯的错，就是漏掉那个关键的 --tree 参数。如果只输入 composer show，你看到的只是一个扁平的包列表，各个依赖之间的父子嵌套关系完全被隐藏了。

这里有三个关键点需要牢记：

• 命令必须在项目的根目录（也就是包含 composer.json 的那个文件夹）下执行。
• 万一系统提示 Command "show" is not defined，那基本可以断定是 Composer 版本太老了，赶紧用 composer self-update 升级一下。
• 输出结果默认是按包名的字母顺序排列子依赖的，这既不是它们的安装顺序，也不代表它们在自动加载时的优先级。

如何过滤特定包的依赖路径

依赖树太庞大，只想看某个特定包（比如 monolog/monolog）是怎么被引进来的？最快捷的方法是用 grep 命令配合过滤：

composer show --tree | grep -A 5 -B 5 "monolog"

不过要注意，grep 可能会打乱原本的缩进格式，导致层级判断出错。更稳妥的做法是分两步走：

• 先把完整的依赖树导出到文件：composer show --tree > deps.txt
• 然后用文本编辑器打开 deps.txt，直接搜索目标包名。这时候，观察包名前面的空格数量就行了——每两个空格，就代表一级依赖深度。
• 对了，还得留个心眼，有时候同一个包的不同版本（比如 symfony/console v5.4.0 和 v6.2.0）可能会同时存在，别搞混了。

为什么有时依赖树里看不到你刚 require 的包

明明刚用 composer require 添加了新包，一查依赖树却没有？别急，这通常是因为一个步骤被忽略了：composer install 或 composer update。

要知道，composer show --tree 读取的是 vendor/composer/installed.json 这个实际安装记录文件，而不是 composer.json 里的声明。所以：

• 运行 composer require foo/bar 之后，如果跳过了安装步骤，新包自然不会出现在树里。
• 如果命令里带了 --no-install 或 --dry-run 这类参数，也不会真正写入 vendor 目录。
• 最直接的验证方法，就是去 vendor/ 目录下看看，对应包的文件夹是不是已经存在了。

替代方案：用 composer why 查单个包的引入原因

比起在庞大的依赖树里大海捞针，有时候我们更关心某个包“为什么会被装进来”。这时候，composer why 这个轻量级命令就派上用场了：

• 输入 composer why monolog/monolog，它会直接告诉你，是哪个顶层包（比如 lara vel/framework）依赖了它。
• 加上 --recursive 参数，比如 composer why --recursive monolog/monolog，就能展开所有上游的依赖路径，效果类似于查看该包的子树。
• 需要注意的是，这个命令不显示版本冲突或者包替换（replace）的关系。遇到这类复杂情况，还得回头去检查 composer.json 文件。

最后提个醒：依赖树本身不会体现“虚拟包”或自动替换的逻辑。举个例子，monolog/monolog 可能声明自己提供了 psr/log 接口的实现。这时候，依赖树里可能看不到独立的 psr/log 包，但它的功能已经被满足了。如果心存疑虑，可以用 composer show psr/log 来确认一下实际的提供者是谁。