-vvv是唯一能定位Composer底层网络异常的开关，因其输出cURL原始请求、未解压响应体、SSL错误详情、连接重置提示及zlib解码失败等关键信息，而-v和-vv仅显示表层动作，无法暴露真实卡点。
直接结论：-vvv 是唯一能定位 Composer 底层网络异常的开关，-v 和 -vv 几乎没用。 它不是“多打点日志”，而是打开 cURL 原始请求、未解压响应体、临时文件路径、SAT 求解器步骤等底层通道。卡在 Loading composer repositories？停在 Resolving dependencies through SAT？报 Failed to decode response 或 Connection reset by peer？这些全得靠 -vvv 才能看到真实原因。
为什么 -v 和 -vv 看不到网络卡点
它们只显示表层动作：-v 告诉你 “正在加载仓库”，-vv 可能打印 HTTP 200/404 状态码，但以下关键信息完全不出现：
- 实际发起的完整 URL（比如是
https://mirrors.aliyun.com/packagist/p2/monolog/monolog.json还是官方源） - cURL 请求头（User-Agent、Accept-Encoding）、原始响应体（尤其是 gzip 压缩前的 JSON）
- SSL 握手失败的具体错误（如
SSL certificate problem: unable to get local issuer certificate） - 连接被重置时的底层提示（如
cURL error 56: OpenSSL SSL_read: Connection reset by peer）
用 -vvv 抓住三类典型网络异常
运行 composer install -vvv 2>&1 | tee debug.log 后，重点 grep 这三类线索：
-
SSL 类：
grep -i "ssl\|certificate\|ca-certificates" debug.log→ 若看到curl.cainfo is not set或证书路径不存在，说明 PHP 缺失 CA 配置 -
连接类：
grep -i "connection\|reset\|timeout\|failed to connect" debug.log→ 若卡在GET https://packagist.org/packages.json，且 curl -v 也超时，基本是 DNS 或防火墙问题 -
解码类：
grep -i "zlib\|decode\|gzip" debug.log→ 出现Failed to decode response: zlib_decode(): data error，大概率是中间代理篡改了压缩响应
-vvv 不输出？先查这三件事
它常被静默屏蔽，别急着重试命令：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
config.verbose被设为false：运行composer config -g verbose确认全局值；项目级检查composer.json里是否误加了"config": {"verbose": false} -
config.platform里写了不存在的扩展（如"ext-foobar": "1.0"）：-vvv下会立刻报错退出，根本走不到网络请求阶段 - Xdebug 干扰堆栈：加
COMPOSER_DISABLE_XDEBUG=1再试，否则异常堆栈可能被截断或掩盖真实错误行
诊断通过但 install 仍失败？别信 diagnose
composer diagnose 默认只测 https://packagist.org 的 HTTPS 连通性，它：
- 不读取
composer.json中配置的镜像源，也不受COMPOSER_REPO_PACKAGIST影响 - 只发一次 HEAD 请求，不模拟真实下载 zip、不触发依赖解析、不走 GitHub API
- 所以即使
diagnose显示 OK，install仍可能卡在Downloading https://mirrors.tuna.tsinghua.edu.cn/packagist/p2/laravel/framework.json
真正要验证镜像是否可用，直接跑：composer show -p | head -5 —— 它会真实走当前配置的源。
