“failed to decode response”是Composer收到非JSON响应（如HTML错误页、gzip解压失败、代理劫持等）导致的解析错误；根本原因是HTTP响应体格式异常，而非网络连通性问题。
Composer install/update 报错 “failed to decode response” 是什么问题
这是 Composer 在请求 Packagist 或自定义仓库时，收到的 HTTP 响应体无法被 JSON 解析导致的错误。根本原因不是网络不通，而是响应内容不符合预期格式——比如返回了 HTML（如 503 页面、防火墙拦截页、CDN 错误页），或 gzip 解压失败，或代理/镜像服务返回了截断/乱码数据。
常见触发场景和对应检查点
这个错误往往出现在特定网络环境下，而非代码本身问题。排查要从「请求发出后实际收到了什么」入手：
- 公司内网或校园网启用了透明代理，把
packagist.org的 HTTPS 响应中间劫持并返回了 HTML 登录页或拦截提示 - 配置了国内镜像（如阿里云、腾讯云），但镜像源临时异常，返回了 502/504 HTML 页面而非 JSON
- 本地启用了
http_proxy或https_proxy环境变量，且代理不可用或不支持 HTTPS 隧道 - PHP 的
openssl扩展缺失或版本过低，导致 TLS 握手降级后响应体损坏 - 运行
composer clear-cache后仍复现，说明不是缓存污染，而是实时响应异常
快速验证和临时绕过方法
先确认是不是响应体本身出问题，而不是 Composer 解析逻辑：
- 手动执行：
curl -v https://packagist.org/packages/list.json，观察真实返回内容是否为合法 JSON（开头是{"packages":{...}}）；如果返回的是 HTML，就坐实了中间拦截 - 临时禁用镜像：
composer config -g repo.packagist composer https://packagist.org，排除镜像服务问题 - 临时关闭代理：
unset http_proxy https_proxy && composer update（Linux/macOS）；Windows 用户检查系统环境变量或 Git Bash 设置 - 加
-vvv参数看完整请求头与响应头：composer update -vvv，重点关注Content-Encoding: gzip是否存在，以及响应体前几十字节（curl输出里会显示）
长期稳定方案和配置建议
真正解决需要分层处理：网络层保证通路干净，Composer 层避免压缩/编码歧义：
- 若在企业网络，优先联系 IT 部门放行
packagist.org:443的直连，不要依赖自动代理 - 国内用户建议固定使用可信镜像，并定期检查其可用性：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 在
php.ini中确认开启extension=openssl和zlib，否则 Composer 内置的解压逻辑可能失败 - 极少数情况是 PHP cURL 版本太老（如 CentOS 7 自带的 7.29），升级到 7.4+ 或手动编译新版 cURL 可解决 gzip header 处理异常
- 不要在
composer.json中写死"repositories"指向不可控的私有源，除非你完全掌控其响应格式和稳定性
最隐蔽的坑是：某些代理在 HTTPS CONNECT 失败后，会伪造一个“友好”的 HTML 错误页返回给客户端，而 Composer 默认把它当 JSON 解析——这种情况下，-vvv 输出里能看到明显的 HTTP/1.1 200 OK + HTML 开头，却报 JSON decode error，务必盯住原始响应体。
