-v、-vv、-vvv 分别对应基础流程、依赖解析与HTTP细节、全量调试信息；-vvv可暴露cURL请求、SAT求解过程及错误原因，但受config.verbose、platform配置等影响，需配合--no-config、--profile等参数精准定位问题。
直接加 -v、-vv 或 -vvv 就行，但级别选错反而更难定位问题
-v 只显示“正在安装什么包”，适合确认流程是否卡住；-vv 开始暴露依赖解析逻辑、HTTP 状态码、配置加载路径；-vvv 才真正进入调试层——它会打印完整 cURL 请求头/体、JSON 响应原始内容、未压缩的元数据流、临时文件路径，甚至 SAT 解析器每一步筛选候选版本的过程。
- 如果你看到
Resolving dependencies through SAT但没后续，说明卡在依赖求解阶段，-vv能看到约束条件，-vvv才能看到具体哪个包的哪个版本被排除及原因 -
composer install -vvv卡在Downloading https://www.php.cn/link/c5b3da73adacd81b5962e60b6b987e52？这不是 Composer 没反应，而是底层 cURL 在 DNS 或 TLS 握手环节挂起，-vvv不会显示 socket 超时，得配合curl -v https://www.php.cn/link/307e9c61450651aa146fa8da4ddd4906验证 -
-vvv日志里出现Failed to decode response: zlib_decode(): data error，大概率是响应 gzip 损坏，可临时加--no-plugins排除插件干扰
-vvv 不生效？先查配置和环境变量有没有偷偷关掉它
config.verbose 设为 false 会强制屏蔽所有 verbose 输出，优先级高于命令行参数；config.platform 中写了不存在的扩展（比如 "ext-foobar": "1.0"），Composer 会在 -vvv 下立刻报错退出，根本不会走到依赖解析环节。
- 运行
composer config --list，重点检查config.verbose和config.platform - 临时绕过所有配置：加
--no-config，例如composer install -vvv --no-config - 某些 CI 环境默认启用 xdebug，反而掩盖真实异常堆栈，加
COMPOSER_DISABLE_XDEBUG=1再试 - 内存不足时 Composer 可能静默中断，加
COMPOSER_MEMORY_LIMIT=-1防止截断
别只盯着 -vvv，组合参数才能快速锁定根因
单纯堆日志量容易淹没关键线索。真正高效的调试是让不同参数各司其职：
- 加
--profile显示每步耗时，一眼看出是 metadata 加载慢、还是 zip 解压卡住 - 加
--no-cache排除本地缓存损坏干扰，确认问题是否复现 - 加
--ignore-platform-reqs（谨慎）验证是否 PHP 版本或扩展缺失导致失败 - 重定向保存：
composer update -vvv 2>&1 | tee debug.log，避免终端滚动丢失前几行 - Windows PowerShell 默认截断长行，改用
cmd或加2>&1 | more分页
composer.lock 会无视镜像配置，这是 -vvv 也救不了的隐藏陷阱
即使你已执行 composer config -g repo.packagist.org https://www.php.cn/link/1569ae888190eb8c53b218b0d529e1e9，只要 composer.lock 文件存在，Composer 就严格按它里面记录的 dist.url 下载——可能是旧的 GitHub URL，也可能是失效的私有源地址。
- 查看
-vvv日志中实际请求的 URL，如果仍是https://www.php.cn/link/e41bbd4af5da30044b88dc9ab711c5b2或codeload.github.com，基本就是 lock 文件“硬编码”了源 - 临时解法：删掉
composer.lock，再跑composer install -vvv，观察是否切到镜像地址 - 长期解法：用
composer update --lock强制刷新 lock 文件中的 dist URL
-vvv 是把双刃剑：它不解决网络不通、DNS 污染、SSL 证书过期这些底层问题，只是把 Composer 看到的“最后一公里”暴露出来。真卡住了，别光刷日志，该抓包抓包，该查 openssl s_client 查 openssl s_client。
