只有 -vvv（三个 v）才能看到 Composer 依赖求解器的真实决策链：从 Resolving dependencies through SAT 开始，到 Rejecting monolog/monolog:1.5.0，再到精确的 because vendor/a requires b:^2.0 因果路径。
composer install -vvv 输出什么才算真·排错日志
只有 -vvv（三个 v）才能看到 Composer 依赖求解器的真实决策链：从 Resolving dependencies through SAT 开始，到 Rejecting monolog/monolog:1.5.0，再到精确的 because vendor/a requires b:^2.0 因果路径。这不是“多打几行”，而是唯一能看到“为什么某个版本被踢出”的通道。
-v：只显示下载进度和包名，对定位冲突无效-vv：出现版本尝试记录（如 Checking platform requirements for package foo），但不展示回溯逻辑-vvv：所有输出走 stderr，含原始 HTTP 响应、插件异常堆栈、缓存命中详情、规则编号（如 rule #127）
为什么 grep 不到 -vvv 日志里的关键信息
Composer 把所有 -vvv 输出都扔进 stderr，而 grep 默认只读 stdout。不重定向，就等于对着空气过滤。
- 正确写法：
composer update -vvv 2>&1 | grep "because" - 查是否走镜像源：
composer install -vvv 2>&1 | grep "mirrors.aliyun.com" - 看脚本执行顺序：
composer install -vvv 2>&1 | grep "Executing script" - CI 或 Docker 中加
--no-ansi防止控制字符污染：composer install -vvv --no-ansi 2>&1 > debug.log
COMPOSER_VERBOSE_SOLVER=1 是深挖“为什么拒绝”的开关
当你已确认冲突存在、但 -vvv 日志太长难定位时，这个环境变量能聚焦求解器每一步判断逻辑。
- 输出示例：
Decision: monolog/monolog==1.5.0 (by rule #127)，往上翻就能找到rule #127对应哪条require或conflict声明 - 必须搭配
-vv使用（-vvv反而会稀释重点） - 不打印 HTTP 或插件异常，只回答“solver 怎么想的”
- 启用方式：
COMPOSER_VERBOSE_SOLVER=1 composer update -vv
别信 --dry-run，它根本不会触发真实校验
composer update --dry-run -vvv 看起来安全，但它跳过锁文件写入、平台扩展检查（如 ext-redis 缺失）、甚至部分缓存一致性验证。真实执行报错的地方，--dry-run 可能完全沉默通过。
常见静默失效场景：
-
config.verbose被设为false，命令行-vvv会被无视 -
config.platform里写了不存在的扩展（如"ext-foobar": "1.0"），Composer 会在-vvv下立即退出，根本走不到依赖解析 - 开了 Xdebug？加
COMPOSER_DISABLE_XDEBUG=1再试，否则堆栈可能被截断或掩盖真实错误
真正有用的日志全靠命令行实时输出，关掉终端就没了；~/.composer/log 或 ~/.composer/logs/composer.log 里基本没有运行时依赖解析内容，全是初始化失败快照。想留档，必须用 2>&1 重定向——这是最容易被跳过的一步，也是最不可替代的操作。
