-vvv是唯一能暴露Composer真实报错根源的方式，因其输出cURL原始请求、SAT求解步骤、插件堆栈、扩展缺失提示及未解压响应体等底层信息，而-v和-vv仅显示表层动作，无法定位SAT卡死、gzip解码失败、SSL静默中断等核心问题。
加 -vvv 才能看到真实报错，-v 和 -vv 基本没用
Composer 默认会吞掉关键错误细节，-v 只告诉你“正在装 xxx”，-vv 多打几行 HTTP 状态码，但真正卡死的地方——比如 SAT 求解器无限回溯、zlib_decode(): data error、插件抛出未捕获异常、cURL SSL 被静默中断——全看不到。-vvv 是唯一能暴露这些的开关，它会打印：
- 完整 cURL 请求头与原始响应体（含未解压 JSON）
- SAT 求解器每一步排除了哪个版本
- 临时文件路径、插件堆栈、
ext-foobar在config.platform里写了但没装的提示
看到日志停在 Resolving dependencies through SAT 后无下文？不是网络问题，是逻辑卡死。看到 zlib_decode(): data error？说明中间代理损坏了压缩流。
-vvv 不输出？先查这三件事
-vvv 被静默屏蔽比想象中常见，别急着重试命令：
-
config.verbose被设为false：优先级高于命令行参数，运行composer config --list | grep verbose确认 -
config.platform里写了不存在的扩展（如"ext-foobar": "1.0"）：Composer 在-vvv下会立刻报错退出，根本走不到依赖解析 - 被 Xdebug 干扰：加
COMPOSER_DISABLE_XDEBUG=1再试；否则堆栈可能被截断或掩盖真实错误
终端滚动太快？用重定向最可靠：composer update -vvv 2>&1 | tee debug.log，之后 grep -i "error\|exception\|failed\|zlib\|SAT" debug.log 快速聚焦。
脚本执行失败只显示 “Script failed”，怎么看到真实错误
Composer 默认静默吞掉子进程的 stderr，你只看到 Script xxx handling yyy returned with error code 1，却不知道哪行 PHP 崩了。关键不是加日志，而是让底层命令的错误原样透出：
- 必须用
-vvv：只有它会显示每条执行的脚本命令、完整环境变量、及其退出时的原始stderr - 常见真实错误只在
-vvv下可见：Fatal error: Uncaught Error:、ParseError、Class not found - 如果脚本是 PHP 文件，检查开头是否有
#!/usr/bin/env php和可执行权限（Linux/macOS）；Windows 推荐显式写"php script.php"，避免系统找不到解释器
特别注意：即使 -vvv 最后显示 Script terminated with exit code 255，也要往上翻 10–20 行找真正触发它的那条。
依赖冲突不明确？用 --verbose 定位回溯路径
--verbose（等价于 -v）虽不如 -vvv 底层，但在依赖解析阶段足够揭示回溯逻辑：
- 它会打出
Resolving dependencies through SAT → Looking at all rules → Trying rule: monolog/monolog == 3.5.0这类中间状态 - 注意看最后几行：如果反复出现
Skipped + 包名 + because it requires php ^8.1，说明 PHP 版本是瓶颈，不是包本身冲突 - 别和
--dry-run混用——--dry-run会跳过实际安装，--verbose在 dry-run 下依然有效，但日志量少很多
真正难定位的卡点，往往不在第一眼报错行，而在 -vvv 日志里某处被缩进埋掉的插件堆栈、gzip 解码失败提示，或者 config.platform 中一个拼错的扩展名。这些细节一旦漏看，就会反复重试无效操作。
