直接看依赖树：用 composer show --tree 最靠谱
想一眼看清项目里“谁依赖了谁”，composer show --tree 是 Composer 官方最稳定、最直观的命令，不需要插件，也不依赖实验性配置。
- 必须在含
composer.json的项目根目录运行，否则报错或输出为空 - Composer 版本低于 2.0 会提示
Command "show" is not defined，需先执行composer self-update - 默认只展示
require中的包及其传递依赖，require-dev里的包不会出现在主树中——除非被某个生产依赖间接拉进来 - 输出缩进即层级：比如
guzzlehttp/guzzle下缩进显示psr/http-client，说明 Guzzle 明确依赖它；若同一包在两处不同缩进出现，大概率存在多路径引入，是版本冲突高发区
查“谁在用这个包”：别混淆 why 和 depends
composer why vendor/package-name 是查引用源的主力命令；而 composer depends 是 2.4+ 实验功能，默认禁用，且容易漏判——尤其遇到 replace、provide 或 path 类型仓库时。
-
composer why symfony/http-kernel会告诉你：是laravel/framework要求^6.0，才把它装进来 - 加
-t参数可展开完整路径：composer why -t symfony/http-kernel，看清从 root 到目标包的每一步约束 - 如果
depends没输出，不代表没人用它——可能只是没被直接声明依赖，而是通过replace或自动加载逻辑间接使用，此时应优先信why或回看show --tree全局结构
过滤和聚焦：用对参数才能避免信息过载
全量依赖树动辄几百行，不加限制根本没法读。关键参数不是可选项，而是必选项。
-
--no-dev：排除开发依赖，专注生产链路；很多冲突其实来自phpunit或phpstan拉进来的旧版组件 -
vendor/package-name（带命名空间）：不加包名就扫全量，加了就精准定位某条支线，例如composer show --tree --no-dev guzzlehttp/guzzle -
--remote：未安装包也能查依赖，适合安装前评估，如composer show --remote --tree doctrine/orm - 别用
--dev单独查开发依赖树——它不会过滤掉生产依赖，反而让输出更混乱；真要查 dev 链，用composer show --tree --dev+ 包名更可控
依赖分析不是终点，而是调试起点
看到树 ≠ 解决问题。真正卡住你的，往往是版本约束冲突、平台不匹配或隐式替换，而这些信息藏在树之外。
- 发现某包有多个版本共存？立刻接一句
composer why-not vendor/package version，验证升级是否可行 - 怀疑某个旧版组件被锁死？用
composer show --tree找到它的上游，再对那个上游运行composer why，逐层上溯 -
composer.lock才是真实快照，show --tree反映的是 lock 文件当前状态；如果刚改过composer.json但没install，树不会变 - 脚本解析
composer.lock或用componizer.net可视化，适合复杂项目快速抓重点，但别替代命令行实时验证
依赖树本身很安静，但你得知道往哪棵树下挖——缩进、包名、版本号、why 输出里的箭头方向，这些细节才是线索真正的落点。
