composer show --tree 显示为空或报错，通常因 Composer 版本低于 2.2.0（该参数自 2.2.0 引入），需升级并确保项目已执行 composer install；指定包名可精准查看其正向依赖路径，区别于 composer depends 的反向依赖查询。
composer show --tree 为什么显示为空或报错
执行 composer show --tree 却看不到依赖树，大概率是因为你用的是 Composer 2.2 之前的版本——这个参数是 Composer 2.2.0 才正式引入的。低于该版本会提示 Unrecognized option: --tree 或直接忽略参数。
验证方式：运行 composer --version，输出应为类似 Composer version 2.2.0 (or higher)。若版本过低，请先升级：
composer self-update
- 升级后仍无效？检查当前目录是否在有效的 Composer 项目中（即存在
composer.json和已执行过composer install） - 如果项目刚初始化但尚未安装依赖，
composer show --tree会返回空结果，而非报错 -
--tree不支持与--platform或--installed混用，否则参数冲突导致静默失败
如何查看某个包的精确依赖路径
composer show --tree 默认展示整个项目依赖树，信息量大且难定位。要聚焦分析单个包（比如排查 monolog/monolog 是被谁拉进来的），需配合包名使用：
composer show --tree monolog/monolog
它会从根项目开始，只展开通向该包的那条（或多条）依赖路径，省去无关分支干扰。
- 路径中出现重复包名（如两处都看到
symfony/console）说明存在多版本共存或版本冲突风险 - 若某包在树中显示为
dev-main或dev-develop，代表它来自 VCS 路径而非稳定 release，可能影响可重现性 - 不加包名时，Composer 会尝试解析所有已安装包，速度较慢；指定包名后性能明显提升
对比 composer depends 和 show --tree 的核心差异
composer depends 和 composer show --tree 都用于查依赖关系，但视角相反、用途不同：
-
composer depends <package>回答：“谁依赖了我？”——列出直接/间接引用该包的上层包（反向依赖） -
composer show --tree <package>回答：“我是怎么被装进来的？”——展示从 root 到该包的完整正向调用链（正向依赖路径） - 例如：运行
composer depends doctrine/annotations可能返回symfony/framework-bundle和phpunit/phpunit；而composer show --tree doctrine/annotations会分别展开这两条路径的具体中间环节 -
depends在 Composer 1.x 中就存在，兼容性更好；--tree更适合调试安装逻辑和版本传递问题
常见误用与隐藏陷阱
实际使用中，几个细节容易导致结论偏差：
- 依赖树基于
vendor/autoload.php状态生成，不是实时解析composer.json。若手动删过 vendor 或改过 lock 文件但未重装，树结构可能过期 -
--tree不显示require-dev包的依赖路径，除非你在运行时加--dev参数：composer show --tree --dev guzzlehttp/guzzle
- 私有仓库或 path 类型仓库中的包，在树中会显示为本地路径（如
../my-internal-lib），而非包名，容易误判来源 - 如果某包被
replace或provide声明覆盖（如psr/log被多个实现提供），--tree显示的是实际安装的那个实现，不是声明方
真正关键的从来不是“能不能看到树”，而是看懂哪一层版本号是锁定的、哪一层是松散约束的——这决定了你改一个 ^ 能不能安全升级，或者为什么 composer update 没动某个子依赖。
