-vvv 是唯一能暴露 Composer 安装卡点根因的开关，它输出原始 HTTP 响应、SAT 求解器步骤、临时路径及插件异常行号；而 -v/-vv 仅显示表层信息，无法揭示 gzip 解码失败、SAT 回溯风暴或扩展缺失等真因。
用 -vvv 而不是 -v 或 -vv 查安装卡点
-vvv 是唯一能暴露 Composer 安装卡死根因的开关。它输出原始 HTTP 响应体、SAT 求解器每一步排除了哪些版本、临时文件路径、插件崩溃的精确行号；而 -v 只告诉你“正在下载”，-vv 顶多显示 404 Not Found，根本看不到 gzip 解码失败或 SAT 回溯风暴。
- 看到
Failed to decode response: zlib_decode(): data error→ 网络中间件（如代理、CDN）损坏了压缩响应 - 日志停在
Resolving dependencies through SAT后无下文 → 不是网络问题，是约束太紧导致求解器陷入死循环 - 出现
Exception trace→ 直接定位到哪个插件、哪行 PHP、甚至哪个扩展缺失（如ext-foobar在config.platform里写了但没装） - 先确认
config.verbose没被设为false，否则-vvv会被静默忽略 - 若用了 Xdebug，加
COMPOSER_DISABLE_XDEBUG=1再试，否则堆栈可能被截断
保存并快速过滤 -vvv 日志的关键操作
终端滚动太快，错误一闪而过，必须重定向保存再分析：
- 运行
composer update -vvv 2>&1 | tee debug.log，完整捕获所有输出 - 用
grep -i "error|exception|failed|zlib|SAT" debug.log快速聚焦关键行 - 特别注意日志开头几行：
Reading ./composer.json failed说明 JSON 格式错误，比后面几百行冲突更早暴露根因 - 若日志被截断，加
COMPOSER_MEMORY_LIMIT=-1防止内存不足丢内容 - 别盲目堆
-vvv，先用--profile看耗时分布，再针对性加-vvv查某一步
区分 composer install 和 composer require 的报错逻辑
这两个命令触发的流程完全不同，排查方向也得切开：
-
composer install读composer.lock精确还原，报错多在「下载阶段」或「autoload 生成失败」；若composer.lock是刚生成的，优先检查vendor/权限、磁盘空间、或autoload配置语法错误 -
composer require foo/bar要重算依赖树，报错更常出现在「版本冲突」或「平台约束不满足」；若报Conclusion: don't install foo/bar v2.0.0，用composer prohibits foo/bar:^2.0查谁在拦着 - 遇到
Could not fetch https://repo.packagist.org/，先别换镜像：运行curl -I https://repo.packagist.org/packages.json，若返回SSL connect error，基本是 OpenSSL、CA 证书或系统时间偏差（误差超 5 分钟会导致 TLS 握手失败）
类找不到？先查 autoload_psr4.php 而不是重装 vendor
装包成功但运行时报 Class not found，90% 是自动加载映射没生效，不是包没装上：
- 运行
composer dump-autoload -v，它会逐行打印扫描路径、匹配到的类、跳过的文件；输出里完全没出现你的命名空间前缀 →composer.json中autoload配置未被识别（缩进错、逗号漏、引号不闭合） - 提示
Scanning directory src/但没列任何类 → 文件扩展名不是.php，或目录下没有符合命名空间结构的类文件 - 打开
vendor/composer/autoload_psr4.php，找最长匹配前缀：类GuzzleHttpPsr7Request就从GuzzleHttpPsr7开始找（注意末尾反斜杠） -
PSR-4条目末尾缺反斜杠（如"App": "src"而非"App\": "src/"）→ 映射失效但不报错 - 开发中频繁改类名/路径时，别用
dump-autoload -o；优化版映射依赖静态快照，调试阶段优先用不带-o的版本
composer.json 是否合法、composer.lock 是否过期、PHP 环境是否满足平台约束——这些基础层的问题，往往藏在 -vvv 输出最开头几行里。 
