-vvv是唯一能暴露真实报错根因的开关，因其输出SAT求解步骤、原始HTTP响应体、插件异常行号、zlib解码失败等底层信息，而-v和-vv仅显示表层动作，无法定位卡点与真错误。
-vvv 是唯一能暴露真实报错根因的开关，其他参数或配置基本无效。
为什么 -v 和 -vv 常常查不到真错误
-v 只显示包名、进度条、“Generating autoload files”这类表层动作；-vv 会多出远程 URL、平台检查结果和锁文件摘要，但依然不展示 SAT 求解器的回溯链、HTTP 响应体、插件异常行号或 zlib 解码失败这类底层问题。很多“卡住没输出”“报错模糊”的情况，根本原因藏在 -vvv 才打开的层级里。
- 看到
Failed to decode response: zlib_decode(): data error→ 网络中间件（如代理、CDN）损坏了压缩响应 - 日志停在
Resolving dependencies through SAT后无下文 → 约束太紧导致求解器陷入死循环，不是网络问题 - 出现
Exception trace→ 直接定位到哪个插件、哪行 PHP、甚至哪个扩展缺失（如ext-redis在config.platform里写了但没装）
-vvv 输出全走 stderr，不重定向就等于没看
所有关键日志（包括 because 因果链、HTTP 响应头、规则编号 rule #127）都写入 stderr，直接 composer update -vvv | grep "monolog" 是空的——因为 grep 默认只读 stdout。
- 快速截取开头逻辑：
composer install -vvv 2>&1 | head -n 200 - 存档备查：
composer install -vvv --no-ansi 2>&1 > debug.log（--no-ansi防止 CI/Docker 里控制字符污染） - 实时看+落盘：
composer update -vvv 2>&1 | tee debug.log
别信 config.verbose 或 COMPOSER_DEBUG=1 的“全局设置”
"config": { "verbose": true } 在 composer.json 中完全被忽略；COMPOSER_DEBUG=1 虽然能默认开启调试，但它不等价于 -vvv，仍可能漏掉 SAT 求解细节和原始 HTTP 响应。最可靠的方式永远是命令行显式加 -vvv，配合重定向。
- 别用
alias composer='composer -vv'—— 日常命令会被冗余日志淹没，反而掩盖真问题 - CI/CD 中务必加
--no-ansi，否则颜色控制符会污染日志解析 - 内存不足时
-vvv日志会被截断，临时加COMPOSER_MEMORY_LIMIT=-1再跑
真正卡点往往出现在日志最开头几行：Reading ./composer.json failed 说明 JSON 格式错误，比后面几百行冲突更早暴露根因；而 Could not fetch https://repo.packagist.org/ 这类错误，得先确认是否镜像不可达，再决定要不要 --no-cache 强制走真实请求。
