要查看 composer 依赖解析过程，需使用 -v 或 -vv 参数：-v 显示依赖图构建、版本匹配与冲突检测关键节点；-vv 还包含 constraint 拆解和 candidate 排序等内部逻辑，且必须配合 --no-progress 保存日志才清晰可用。
Composer install/update 时怎么看到依赖解析过程
Composer 默认不输出依赖解析的详细步骤，只显示最终安装结果。想看它怎么一步步推导出版本选择、为什么拒绝某个包、冲突发生在哪一环，必须开启 --verbose 或更细粒度的日志模式。
最直接有效的方式是加 -v（等价于 --verbose），它会让 Composer 输出 resolver 的每一轮尝试和回溯。如果还不够，用 -vv 可看到更多内部状态，比如 constraint 拆解、package candidate 排序逻辑。
-
composer install -v：显示依赖图构建、版本约束匹配、冲突检测关键节点 -
composer update guzzlehttp/guzzle -vv：聚焦单包更新时的完整解析链，包括其所有依赖的 constraint 传播路径 - 避免只用
--dry-run：它跳过实际解析，不触发 resolver 日志，无法替代-v
为什么 composer why-not 比日志更快定位冲突根源
当 composer update 报错 Conclusion: don't install vendor/package v1.2.0 这类信息时，翻 verbose 日志要手动逆向追踪几十行——而 composer why-not 是专为这个场景设计的诊断命令。
它不依赖日志输出，而是直接复现 resolver 的失败路径，给出从 root 到冲突点的最小依赖链。例如：
composer why-not monolog/monolog:^2.0
会明确告诉你：your-project 要求 symfony/console:^5.4，而该版本锁死了 psr/log 为 ^1.0，但 monolog/monolog:^2.0 要求 psr/log:^2.0 —— 冲突闭环清晰可见。
- 必须指定完整包名+版本约束，如
monolog/monolog:^2.0，不能只写monolog/monolog - 对 dev-main 或分支别名（如
dev-develop）支持有限，优先用稳定版本号测试 - 它不依赖当前 lock 文件是否最新，即使
composer.lock已过期也能运行
如何保存解析日志供后续分析
终端滚动太快，或者需要发给同事协同排查，就得把 verbose 输出存成文件。注意不是简单重定向 2>&1 就完事——Composer 有些日志走 stderr，有些走 stdout，且部分提示（如进度条）会覆盖前文。
正确做法是禁用进度条并强制全量输出到文件：
composer update --no-progress -vv > composer-resolve.log 2>&1
-
--no-progress关键：避免 ANSI 控制符混入日志，否则打开文件全是乱码或空行 - 务必用
-vv，-v有时会省略 resolver 的中间决策，导致日志断层 - 日志体积可能达 MB 级，特别是大型项目，建议先用
composer update foo/bar -vv聚焦单包缩小范围
依赖解析慢时，日志里哪些线索值得立刻关注
如果 composer update 卡在 “Resolving dependencies through SAT” 超过 30 秒，verbose 日志里出现高频重复模式，基本可判定是约束设计问题。
重点扫描以下几类行：
- 大量重复的
Checking <code>foo/barfor version X.Y.Z：说明某包被反复试探不同版本，可能因conflict规则太宽或replace配置异常 - 持续出现
Skipped branch X, no versions match constraint Y：尤其当 Y 是类似^1.0 || ^2.0这种松散约束，Composer 会逐个分支检查，拖慢速度 - Resolver 回溯深度超过 15 层（日志中
Backtracking...行连续出现）：通常意味着 rootrequire中存在隐式互斥，比如同时 require 了两个强绑定不同 psr/log 版本的库
这些不是日志“噪音”，是 resolver 在真实求解过程中的压力信号——改掉对应约束，速度常能提升一个数量级。
