Composer如何查看依赖关系树_排查包冲突的层级结构【深度解析】-composer-PHP中文网

不能，composer show --tree 会报错，正确命令是 composer show -t（仅 Composer 2.0+ 支持）；1.x 需用 composer depends --tree 或升级版本。

composer如何查看依赖关系树_排查包冲突的层级结构【深度解析】

不能。Composer 本身没有内置的 --tree 参数，运行 composer show --tree 会报错：Unrecognized option "--tree"。这是新手最常踩的第一个坑——误信过时文档或社区旧帖里的“伪命令”。

真正可用的是 composer show -t（-t 是 --tree 的别名，但仅在 Composer 2.0+ 支持；1.x 完全不识别）。确认版本：运行 composer --version，低于 2.0.0 就得换方法。

composer why 回答“谁要求了这个包”，composer depends 回答“谁被这个包依赖”。二者方向相反，但常被混用排查冲突——结果对不上，往往是因为锁文件（composer.lock）里记录的版本和 composer.json 声明的约束不一致。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

composer why guzzlehttp/guzzle 显示 monolog/monolog 引入它 → 说明 monolog 是直接依赖项，且其 composer.json 声明了 guzzle
composer depends guzzlehttp/guzzle 却没列出 monolog？大概率是 monolog 在 lock 文件中实际安装的是不带 guzzle 的精简版（比如 monolog v2.0+ 默认不硬依赖 guzzle，除非你显式 require）
真实依赖链可能被 replace、provide 或 conflict 规则截断，此时 composer show -t 会显示 (replaced) 或 (provided) 标记，需人工对照各包的 composer.json

这类错误不指明具体哪个包卡住，只甩出一堆候选版本，本质是 SAT 求解器失败。关键不是看报错末尾的“candidate versions”，而是翻到日志开头找第一处 Root package requires... 和 ...is locked to version... 的冲突点。

加 -v 参数重试：composer update -v，输出里会逐行打印约束推导过程，找到最早出现 can only install one of 的位置
用 composer prohibits vendor/package:version 直接测试某个组合是否可行，例如 composer prohibits laravel/framework:v9.0.0 guzzlehttp/guzzle:^7.0
临时删掉 composer.lock 再 composer update --dry-run，能绕过锁文件干扰，暴露纯声明层面的冲突（但慎用于生产环境）

这是 Composer 显式告诉你：“这个包不是从 packagist.org 正常安装的，而是通过 VCS 直接拉的开发分支或某次提交”。它本身不是错误，但极易引发隐性冲突。

如果两个不同包都 require 同一个库的 dev-master，但指向不同 commit，Composer 无法自动合并，会直接拒绝安装
#commit-hash 版本无法被语义化版本规则匹配，^2.0 这类约束对它完全无效，容易在后续 composer update 中意外降级或跳变
检查方式：composer show -t | grep "#" 或 composer show -t | grep "dev-" ，发现后应尽快替换为稳定版本或至少固定到 dev-master#abc123 形式

依赖树不是静态快照，它随 composer.json 修改、composer.lock 更新、甚至 packagist 元数据变更而动态变化。每次怀疑冲突，先确认你分析的是当前 lock 文件所固化的那棵树，而不是“理论上应该有的结构”。