composer why 只显示直接依赖，不展开完整层级；查完整路径需用 composer show --tree（兼容旧版）或 composer depends --tree（composer 2.5+），后者更快但需注意版本与 --dev 参数。
composer why 显示的是直接依赖，不是完整层级
执行 composer why vendor/package 只会返回「谁直接 require 了它」，不会展开下游依赖链。比如 A → B → C，查 C 时只看到 B，看不到 A。这不是 bug，是设计使然——composer why 的语义就是「谁在 composer.json 里写了它」。
常见误判场景：你删掉一个包后 composer install 报错，用 composer why 却查不到谁在用它，其实它被某个间接依赖拉进来了。
- 想看完整路径，必须用
composer depends --tree（Composer 2.5+）或composer show --tree -
composer why不支持--recursive或-r参数，加了会报错：Unrecognized option: --recursive - 如果项目用了
replace或provide，composer why可能完全不显示结果，因为那不是「require 关系」
composer show --tree 查依赖树的实操要点
composer show --tree 是目前最可靠的递归依赖查看方式，但它默认只显示当前已安装的包，且输出可能很长。关键不是“能不能看”，而是“怎么看准”。
- 加
--platform可包含 PHP 扩展等平台依赖（如ext-curl），避免漏掉隐式约束 - 用
grep过滤目标包更高效：composer show --tree | grep -A5 -B5 "vendor/package" - 注意缩进层级：每级缩进代表一层依赖关系，但 Composer 不保证缩进严格对齐（尤其含中文包名或特殊字符时）
- 若提示
Package not found，说明该包未被解析进 lock 文件，可能已被移除、替换，或仅存在于 require-dev 中
composer depends --tree 的兼容性陷阱
composer depends --tree vendor/package 看起来更精准，但它在 Composer 2.4 及更早版本中不存在——这是 2.5 引入的新命令。很多 CI 环境或老旧服务器仍跑着 2.4.x，直接执行会报错：Command "depends" is not defined.
- 先确认版本：
composer --version，输出含2.5.才能用depends --tree - 2.4 及以下只能退回到
composer show --tree+ 手动向上追溯 -
depends --tree不受require-dev影响，默认只查生产依赖；要查 dev 依赖，得加--dev参数 - 它比
show --tree更快，因为不加载整个依赖图，只从目标包反向遍历
为什么深度分析容易出错？三个现实限制
依赖层级不是静态树，它受 composer.json 中的 minimum-stability、prefer-stable、平台配置甚至本地 config.json 影响。同一份 composer.lock 在不同机器上解析出的深度可能不一致。
- 版本约束冲突时，Composer 可能跳过某条路径，导致你看到的“最短路径”实际不可达
- 私有仓库或 VCS 包若不可访问，
--tree输出会中断，后续层级丢失，但不会报错提示 - PHP 版本不匹配会导致某些包被自动排除，而
show --tree仍把它列出来（只是标为[not installed]），容易误判是否真被依赖
真正需要深度分析时，别只信命令输出——得结合 composer.lock 里的 packages 和 packages-dev 字段手动验证路径是否存在。
