正确用法是直接运行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）是怎么被引入的，用 composer show --tree 配合 grep 最快：

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

但要注意：grep 会截断缩进，可能误判层级。更稳妥的方式是先导出为文本再查：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• composer show --tree > deps.txt
• 用编辑器打开 deps.txt，搜索目标包名，观察其前导空格数（每两个空格 = 一级依赖深度）
• 注意同名不同版本的情况，如 symfony/console v5.4.0 和 v6.2.0 可能同时存在

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

最常见原因是没执行 composer install 或 composer update —— composer show --tree 读取的是 vendor/composer/installed.json，不是 composer.json 的声明。

• 刚运行 composer require foo/bar 后立即执行 show --tree，若跳过了安装步骤，新包不会出现在树中
• 如果用了 --no-install 或 --dry-run，也不会写入 vendor
• 检查 vendor/ 目录是否存在对应包的文件夹，这是最直接的验证方式

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

比起扫完整树，查某个包“为什么被装进来”更常用，composer why 是专为此设计的轻量命令：

• composer why monolog/monolog 输出直接依赖它的包（例如 laravel/framework）
• composer why --recursive monolog/monolog 展开所有上游路径，效果接近子树裁剪
• 它不显示版本冲突或替换关系，遇到 conflict 或 replace 字段需回看 composer.json

依赖树本身不体现自动替换逻辑（比如 "psr/log": "^1.0" 被 monolog/monolog 提供），这点容易误读，得结合 composer show psr/log 确认实际提供者。