“Failed to decode response”错误源于网络中间件篡改响应体导致JSON解析失败，而非Composer自身问题；常见原因包括代理、防火墙、抓包工具或安全软件注入HTML/重定向页，需通过curl验证响应内容并绕过中间件排查。
为什么 composer install 突然报 “Failed to decode response”？
这错误不是 Composer 自身解析失败，而是它收到的 HTTP 响应体根本不是合法 JSON —— 通常因为网络中间件（比如公司代理、防火墙、CDN 或本地调试工具）偷偷改写了响应内容，比如注入 HTML 脚本、重定向跳转页、或返回了 502/504 的文本错误页。
典型现象：composer install 卡在 Downloading https://packagist.org/packages.json 后抛出该错误，但用 curl -I https://packagist.org/packages.json 看状态码却是 200；或者你手动 curl 下来的响应开头是 而非 <code>{。
- 检查是否启用了全局代理：运行
echo $HTTP_PROXY和echo $HTTPS_PROXY，非必要时清空它们（unset HTTP_PROXY HTTPS_PROXY） - 确认没开着 Charles / Fiddler / mitmproxy 等抓包工具 —— 它们常会替换证书并篡改响应体
- 如果公司网络强制走透明代理，尝试加
-vvv参数运行composer install，看实际请求发到了哪个 URL（可能被 302 到内部镜像，而该镜像返回了非 JSON 内容）
如何验证 Packagist 响应是否被污染？
绕过 Composer，直接用最简方式复现问题，定位污染源：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 执行
curl -sSL -D - https://packagist.org/packages.json | head -n 20，观察响应头和前几行正文。正常应看到HTTP/2 200+Content-Type: application/json+ 开头为{ - 若看到
HTTP/1.1 302 Found或响应体含，说明中间有重定向或注入行为 - 对比
curl --noproxy "*" -sSL https://packagist.org/packages.json | head -c 50，加--noproxy "*"可绕过系统代理，快速判断是否代理导致
临时绕过中间件的几种实操方式
不改网络环境也能让 Composer 继续工作，关键是让它拿到原始 JSON 响应：
- 强制使用 Packagist 官方镜像（跳过公司镜像）：
composer config -g repo.packagist composer https://packagist.org - 换用可信 DNS，避免 DNS 劫持影响域名解析（如设
1.1.1.1或8.8.8.8） - 如果确定是 TLS 中间人（MITM）干扰，可临时禁用证书校验（仅限排查，勿长期使用）：
export COMPOSER_DISABLE_TLS=1，再运行命令（注意：这会让流量降级为 HTTP，仅用于验证是否为证书层问题） - 某些企业网络会拦截
packages.json但放行 ZIP 包下载，可尝试composer install --no-plugins --no-scripts先拉依赖，再单独处理脚本
为什么改 cafile 或升级 OpenSSL 通常没用？
这个错误跟证书验证失败（如 cURL error 60）是两回事。Failed to decode response 发生在响应已成功接收之后，Composer 尝试 json_decode() 时崩溃。所以：
- 修改
openssl.cafile或更新 CA 证书，对这类问题完全无效 - 升级 Composer 版本也大概率无解 —— 它只是忠实解析服务端返回的内容
- 真正要盯的是“谁在响应到达 Composer 前动了手脚”，而不是 Composer 本身
最容易被忽略的一点：有些安全软件（尤其国内某卫士类）会在后台静默注入 JS 脚本到所有 HTTP/HTTPS 响应中，哪怕你没开浏览器 —— 这种情况只能关掉对应软件或换网络环境验证。
