如何查看Composer在解析依赖时所做的每一个决策？ (–verbose日志)

composer 依赖解析的完整决策链需用 -vvv 模式查看，-v 或 –verbose 仅显示常规日志；composer show –tree 不反映求解过程；定位冲突应优先使用 composer prohibits。

Composer 默认不会告诉你它为什么选择某个版本、为什么拒绝另一个包，--verbose 本身也只输出有限的安装流程信息，**并不能展示依赖解析的完整决策链**。真要看到“每一个决策”，得用更底层的日志模式。

composer install/update 时加 -vvv 才能看到解析器内部动作

--verbose（或 -v）只增加常规日志层级，而真正暴露依赖求解器（Solver）每一步尝试、回溯、约束检查的，是三级详细模式：-vvv。它会打印出 SAT 求解器的原始操作，比如：

• 正在尝试满足 monolog/monolog:^2.0
• 排除版本 monolog/monolog[1.25.0]：与 php ^8.0 冲突
• 回溯到 laravel/framework[9.0.0]，重新尝试 symfony/console 的其他候选

注意：输出量极大，建议配合 grep 过滤关键包名或错误关键词：

composer update -vvv 2>&1 | grep -E "(monolog|conflict|backtrack|selecting)"

composer show --tree 只显示最终结果，不反映求解过程

很多人误以为 composer show --tree 能还原决策路径，但它只是静态展示已锁定的依赖树，**完全不体现 Composer 曾经考虑过哪些版本、为何放弃某些组合**。例如它不会告诉你：doctrine/dbal 最终选了 3.6.0 是因为 laravel/octane 强制要求 ^3.5，而 3.7.0 又被 phpstan/phpstan 的 require-dev 中的 php ^7.4 条件间接排除——这类中间约束只有 -vvv 日志里有痕迹。

想定位具体冲突？优先用 composer prohibits 而非翻日志

当 -vvv 输出太长难以定位时，更高效的方式是直接问 Composer：“谁阻止了我装 foo/bar:2.0？”：

composer prohibits foo/bar:2.0

它会列出所有直接或间接声明了冲突约束的包及其版本条件，比如：

• laravel/framework[10.0.0] requires foo/bar ^1.5
• bar/baz[3.2.1] requires foo/bar

这比在几百行 -vvv 日志里手动找 “rejecting” 更可靠。

自定义 Solver 日志需改源码，不推荐日常使用

Composer 的依赖求解器（composer/semver + composer/dependency-resolver）本身支持更细粒度的调试钩子（如 Solver::setLogger()），但这些接口未暴露给 CLI，启用它们必须临时修改 vendor/composer/composer/src/Composer/Command/UpdateCommand.php 等文件——对绝大多数项目来说，属于过度工程。除非你在开发插件或调试 Composer 自身 bug，否则坚持用 -vvv + prohibits 组合已经覆盖 95% 的真实排障场景。

真正容易被忽略的是：-vvv 日志里那些一闪而过的 “skipping” 和 “forced” 行为——它们往往暗示着 platform 配置、replace 声明或 minimum-stability 正在静默干预结果，而不是版本号本身的问题。