composer show --tree 默认只展开一级依赖，深层结构需结合 -v、--no-dev 或 grep 过滤；报错常因环境未就绪，如 PHP 扩展缺失、私有仓库未配置或平台约束不满足，应先运行 composer diagnose 验证。
composer show --tree 为什么总显示不全或报错
它默认只展开一级依赖，深层冲突藏在底下；遇到循环引用、私有仓库未配置或平台扩展缺失时，会直接中断并报 Could not resolve package。不是命令错了，是环境没准备好。
执行前先确认三件事：
- 运行
composer diagnose，重点看PHP version和Extensions是否满足所有待检包要求（比如symfony/console需要intl） - 若项目含私有包，确保
repositories已在composer.json中正确定义且可访问 - 加
-v参数重试：composer show --tree -v，错误堆栈里通常会暴露具体卡在哪一层
用 --dry-run + -v 看清 update 真实影响范围
直接 composer update 是最危险的操作——它可能把 monolog/monolog 升到 3.x，而你项目里还硬编码调用了已被移除的 Monolog\Handler\NewRelicHandler。
替代方案是模拟执行：
-
composer update vendor/package --dry-run -v：只看变更预估，不改任何文件 - 关注输出中 “Would install” 和 “Would update” 后的版本号，比对 changelog 判定是否含 BC break
- 若输出含大量
downgrading，说明当前composer.lock锁了高版本，但composer.json约束太松（如写的是"^2.0"却锁了2.10.0），此时应先收紧约束再试
composer why-not 比 show --tree 更快定位冲突源头
当你想装 phpunit/phpunit:^10.0 却失败，composer why-not phpunit/phpunit:10.0 会直接告诉你：是 laravel/framework 的 ^9.0 要求 phpunit:^9.5，而两者无法共存。
这个命令不依赖完整解析，响应快、指向准：
- 必须指定完整包名+精确版本，例如
composer why-not myvendor/mypackage:3.2.1 - 若提示
No packages require...，说明该包未被任何已安装依赖声明，冲突来自composer.json的顶层约束 - 配合
composer show -t（显示依赖树缩略版）交叉验证，能快速区分是“间接依赖锁死”还是“顶层约束打架”
锁文件 diff 是判断兼容性风险的最可靠依据
composer.lock 不是日志，它是契约。升级前后对比它，比读文档更真实。
操作流程很轻量：
- 升级前先
git add composer.lock && git commit -m "before update" - 执行
composer update vendor/package --with-dependencies -
git diff composer.lock，重点关注三类变动： - 新增或删除的包行（尤其
ext-*或php行，意味着平台要求变了） - 同一包的
version字段从"2.8.1"变成"3.0.0"（小版本跨大号大概率有 breaking change） -
source类型从"dist"变成"source"（说明某包没发 tag，正在用 dev 分支，不稳定）
真正容易被忽略的是：composer.lock 里的 content-hash 变了，但 diff 看不出哪行代码触发的——这往往是因为 composer.json 里写了 "config": {"sort-packages": true}，导致字段顺序重排。这种变更无害，但会干扰你识别真实风险。
