低带宽下 Composer install 卡在 downloading 主因是 HTTP/1.1 明文传输且未启用 gzip 压缩，导致大包重传超时；真正有效的提速手段是换国内镜像源、使用 --prefer-dist、禁用脚本与自动加载，并确保 zlib 和 cURL 支持 gzip。
composer install 为什么卡在 downloading 包？
低带宽下 composer install 卡住，多数不是网络断了，而是默认走 HTTP/1.1 明文下载 + 未启用 gzip 压缩，单个包几十 MB 的 tar.gz 实际传输量没压缩，TCP 连接反复重传、超时。Composer 本身不控制 HTTP 层压缩，得靠底层 cURL 和远程仓库配合。
如何让 Composer 下载走 gzip 压缩？
关键不在 Composer 配置，而在 PHP 的 cURL 扩展是否启用 Accept-Encoding: gzip，以及 Packagist（或私仓）是否返回压缩响应。实操上要确认三点：
- PHP 编译时需启用
--with-curl，且 cURL 版本 ≥ 7.52.0（旧版对 gzip 支持不稳定） - 确保
zlib扩展已加载（php -m | grep zlib），否则即使服务端返回Content-Encoding: gzip，PHP 也无法自动解压 - 不手动改
composer.json或config.json—— Composer 会自动发带Accept-Encoding: gzip的请求，只要底层支持就生效
验证方式：开一个临时项目，运行 composer install -vvv，看到类似 Downloading https://packagist.org/p/provider-2024-01%24xxx.json 后紧跟着 gzip 字样（cURL 日志里有 Content-Encoding: gzip），说明已启用。
HTTP/2 对 Composer 下载有帮助吗？
有，但前提是 Packagist 官方或你用的镜像站启用了 HTTP/2，且你的 PHP cURL 绑定的是支持 HTTP/2 的 OpenSSL（≥ 1.0.2）和 nghttp2。不过要注意：
- Packagist.org 目前（2024）仍主要跑在 HTTP/1.1 上，国内镜像如阿里云、腾讯云 composer 镜像也基本未开启 HTTP/2
- 即使服务端支持，PHP 默认不强制升到 HTTP/2；
curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_2TLS)这类设置 Composer 内部不暴露，无法直接干预 - 实际影响有限：HTTP/2 的多路复用对 Composer 这种串行拉取少量大文件的场景，不如 gzip 压缩来得直接
低带宽下真正有效的提速手段
别死磕传输层优化，优先做这几件事：
- 换国内镜像源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，延迟降 80%，比 gzip 省下的流量更实在 - 加
--no-scripts --no-autoloader参数跳过非必要步骤，尤其首次安装时避免触发 post-install-cmd 耗时 - 用
composer install --prefer-dist（默认），确保走 zip/tar 包而非 git clone；如果误配了"preferred-install": "source"，带宽压力直接翻倍 - 禁用 HTTPS 验证仅限测试环境：
composer config -g secure-http false，省掉 TLS 握手和证书校验开销 —— 但生产环境绝不可用
gzip 和 HTTP/2 是锦上添花，镜像源 + dist 模式 + 关闭冗余动作，才是低带宽下能立刻见效的组合。服务端没开 gzip？你本地再配也没用；HTTP/2 没落地？先别当真。
