正确命令是composer show --tree，用于查看已安装包的依赖树；查某包用composer show --tree vendor/name，查谁引用它用composer why --tree package，均需composer 2.0+且在项目根目录执行。
直接用 composer show --tree，别试 composer tree 或 composer depends —— 前者是旧插件残留，后者默认关闭且行为不稳定。
查某个包的完整依赖链（正向：它依赖谁）
想看 guzzlehttp/guzzle 实际装了哪些下层依赖，包括递归展开的全部层级，运行：
composer show --tree guzzlehttp/guzzle
关键点：
- 必须在项目根目录执行，且
vendor/已存在（即已运行过composer install） - 不加包名会输出整个项目的依赖树，几百行起步，基本没法扫；加包名才聚焦
- 输出里 “requires” 字段显示的是它
composer.json中声明的约束（如^2.0），不是实际安装版本；要看真实装的哪个版本，得看缩进下一层的包名和版本号 - 如果包是
dev-main或带#commit-hash安装的，--tree仍能显示，但部分间接依赖可能因版本解析失败而截断
查谁在依赖某个包（反向：谁用了它）
想知道 monolog/monolog 是被项目本身、还是 laravel/framework 拉进来的，用：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer why --tree monolog/monolog
注意：
-
composer why比composer depends更可靠——后者需手动开启实验配置experimental.show-depends，且对provide或path类型仓库支持差 -
--tree是关键：不加只返回第一层（比如只显示laravel/framework），加了才能看到最终源头是不是你自己的your-project-name dev-main - 若末尾出现
[dev]，说明来自require-dev；若中断在某一层（比如停在symfony/console就没了），大概率是它通过provide psr/log虚拟声明，没继续向下解析
常见报错和对应解法
遇到命令不识别或输出为空，先核对这几点：
-
Command "show" is not defined→ Composer 版本低于 2.0，运行composer self-update -
Could not find package→ 包名拼错（必须是vendor/name全小写，不能漏斜杠），或该包根本没装进vendor/（比如只在require-dev里但当前没装 dev 包） -
composer show --tree输出空或卡住 →vendor/为空或composer.lock缺失，先跑composer install - 想查未安装包的依赖链 → 加
--remote，例如composer show --tree laravel/framework --remote，但仅反映 Packagist 上声明的约束，不保证本地可装通
真正复杂的地方在于：Composer 的依赖解析是动态的，composer show --tree 显示的是当前 vendor/ 和 composer.lock 的快照，不是 composer.json 里写的理想状态。一旦有 replace、provide、path 或版本冲突，树形结构就可能跳层或中断——这时候得结合 composer why --tree 和 composer show 单个包的结果交叉验证，而不是只信其中一条命令的输出。
