不能，composer show --tree 会报错，正确命令是 composer show -t（仅 Composer 2.0+ 支持）；1.x 需用 composer depends --tree 或升级版本。
composer show --tree 能直接看到依赖树吗
不能。Composer 本身没有内置的 --tree 参数，运行 composer show --tree 会报错：Unrecognized option "--tree"。这是新手最常踩的第一个坑——误信过时文档或社区旧帖里的“伪命令”。
真正可用的是 composer show -t（-t 是 --tree 的别名，但仅在 Composer 2.0+ 支持；1.x 完全不识别）。确认版本：运行 composer --version，低于 2.0.0 就得换方法。
- Composer 2.0+：直接用
composer show -t vendor/package-name查指定包的依赖树 - Composer 1.x：必须升级，或改用
composer depends --tree vendor/package-name（仅限 1.10.0+） - 想看整个项目所有依赖的层级关系？用
composer show -t不带包名，但输出极长，建议配合grep或重定向到文件
为什么 composer why 和 composer depends 结果看起来矛盾
composer why 回答“谁要求了这个包”，composer depends 回答“谁被这个包依赖”。二者方向相反，但常被混用排查冲突——结果对不上，往往是因为锁文件（composer.lock）里记录的版本和 composer.json 声明的约束不一致。
-
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
composer update 报 “found x packages that could not be installed” 怎么定位冲突源头
这类错误不指明具体哪个包卡住，只甩出一堆候选版本，本质是 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，能绕过锁文件干扰，暴露纯声明层面的冲突（但慎用于生产环境）
依赖树里出现 (dev-master) 或 #commit-hash 是好事还是风险
这是 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 文件所固化的那棵树，而不是“理论上应该有的结构”。 
