必须用 -vvv 才能暴露真实失败原因，因其输出 HTTP 响应体、SAT 求解步骤、插件异常堆栈及原始 stderr；-v 和 -vv 仅显示进度或摘要，无法定位依赖冲突、网络中断、autoload 失效等根本问题。
composer install -vvv 是唯一能暴露真实失败原因的命令，其他参数（-v、-vv）对定位依赖冲突、网络中断、插件崩溃或 autoload 失效基本无效。
为什么必须用 -vvv 而不是 -v 或 -vv
-v 只显示“Loading repository”“Installing monolog/monolog”这类进度提示；-vv 多加了 URL 和锁文件摘要，但依然看不到 HTTP 响应体、SAT 求解器步骤、插件异常堆栈或 json_decode() expects parameter 1 to be string, bool given 的原始空响应。只有 -vvv 才会输出：
- GET 请求完整 URL 和原始响应（含空字符串或 gzip 损坏内容）
- SAT 求解器每一步排除了哪个版本，以及原因（如
because myproject requires php ^8.1） - 脚本执行时的真实 stderr，比如
Fatal error: Uncaught Error: Class 'Foo' not found - 插件抛出异常的精确文件路径和行号，甚至
ext-redis缺失却在config.platform中声明的提示
composer install -vvv 必须重定向 stderr 才能查错
Composer 把所有 -vvv 输出都写入 stderr，而 grep 默认只读 stdout。不重定向，grep 就等于在空流里找东西。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 正确写法：
composer install -vvv 2>&1 | grep "error"或composer install -vvv 2>&1 | tee debug.log - CI/Docker 环境务必加
--no-ansi，避免 ANSI 控制符污染日志：composer install -vvv --no-ansi 2>&1 > debug.log - Windows 用户用
findstr替代grep，且2>&1必须写在composer命令之后，顺序错则捕获失败 - 别指望
~/.composer/log：它只记录极少量初始化错误（如 config 加载失败），完全不包含install过程中的任何依赖、网络或脚本日志
常见卡点与对应 -vvv 线索
终端滚动太快不是问题本身，而是线索藏得太深。关键不是看全量日志，而是盯住几类信号：
- 日志停在
Resolving dependencies through SAT后无下文 → 不是网络问题，是约束过紧导致求解器死循环 - 出现
zlib_decode(): data error→ 中间代理或 CDN 损坏了压缩响应，不是 Composer 自身 bug - 看到
Reading ./composer.json failed→ JSON 格式错误或文件权限不足，比后面几百行冲突更早暴露根因 - 报
Script failed却没堆栈 → 往上翻 10–20 行，找Executing script后面那条命令及其 stderr 输出 - 最后显示
exit code 255→ 错误不在末尾，而在它前面那条被截断的 PHP 命令或 cURL 请求
容易被忽略的干扰项
-vvv 不是万能开关，环境干扰会让它失效或输出失真：
- Xdebug 默认会截断或覆盖原始堆栈，必须加
COMPOSER_DISABLE_XDEBUG=1再试 - 内存不足会导致日志中途截断（尤其 Laravel + SDK 多的项目），加
COMPOSER_MEMORY_LIMIT=-1强制不限制 -
config.verbose若被设为false，会静默忽略-vvv，先运行composer config --list | grep verbose确认 - 用了
--no-cache或composer clear-cache再跑，否则你看到的可能是缓存命中的假路径，而非真实请求链
真正难的不是加参数，而是从上万行输出里识别哪一行是根因——它往往出现在开头（JSON 读取失败）、中间（SAT 回溯风暴）、或某条脚本命令的 stderr 里，而不是最后一行报错。
