Composer底层网络库对不同镜像源HTTP/2支持的探究-composer-PHP中文网

composer底层网络库不直接支持http/2，实际是否启用取决于php的curl扩展版本（≥7.47.0）、openssl版本（≥1.0.2）、编译配置及服务端alpn协商；国内阿里云、中科大镜像源对元数据接口已支持http/2，但dist包下载仍多为http/1.1，且镜像url必须以/结尾否则触发降级。

composer底层网络库对不同镜像源http/2支持的探究

Composer底层网络库是否支持HTTP/2

Composer本身不直接实现HTTP协议栈，它依赖cURL（通过PHP的curl扩展）发起网络请求。是否走HTTP/2，完全取决于PHP编译时cURL链接的版本及配置：cURL ≥ 7.47.0 + OpenSSL ≥ 1.0.2 + 编译时启用HTTP/2支持，且服务端也支持ALPN协商，才会实际升级到HTTP/2。

实操中你无法在Composer里开关HTTP/2——它没有--http2这类参数。唯一可控的是：确保你的PHP环境满足上述条件，并用php -r "print_r(curl_version());"检查features字段是否含CURL_VERSION_HTTP2。

阿里云/中科大镜像源是否真正响应HTTP/2

国内主流镜像源（如https://mirrors.aliyun.com/composer/、https://mirrors.ustc.edu.cn/composer/）当前（2026年6月）均支持HTTP/2，但只对特定路径生效：

/packages.json、/p/*.json等元数据接口普遍启用了HTTP/2，可复用TCP连接，减少TLS握手开销
/dist/下的zip包下载仍多为HTTP/1.1，因CDN节点（如阿里云OSS、中科大CDN）对大文件分块传输未强制开启HTTP/2流控

验证方式：运行curl -I --http2 https://mirrors.aliyun.com/composer/packages.json，若响应头含HTTP/2 200即确认支持；若返回HTTP/1.1，说明要么服务端降级，要么本地cURL未启用HTTP/2。

为什么并发下载没提速？可能卡在HTTP/1.1瓶颈

Composer 2.2+默认启用并行下载，但并发效果高度依赖底层协议能力。若镜像源元数据接口走HTTP/2而dist包仍走HTTP/1.1，会出现「元数据快、包下载慢」的错觉——Downloading日志持续卡住，实际是大量HTTP/1.1连接排队等待DNS解析和TCP建连。

CurlShip Directory Submission

向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。

下载

关键干预点：

用export COMPOSER_NO_TLS=1（仅内网可信环境）绕过TLS握手，暴露真实I/O瓶颈
改用composer install --concurrency=15而非默认5，压测镜像源连接池上限
若仍慢，抓包看tcpdump -i any port 443，确认是否有大量SYN重传——这说明不是HTTP/2问题，而是DNS或中间网络抖动

镜像URL结尾少/导致HTTP/1.1 fallback的隐性陷阱

镜像源URL必须以/结尾，否则Composer拼接路径时会丢掉分隔符，触发错误重定向或404，最终退回到HTTP/1.1兜底逻辑：

例如配成https://mirrors.aliyun.com/composer（无尾斜杠），Composer会请求https://mirrors.aliyun.com/composerpackages.json → 404 → 自动fallback到https://packagist.org/packages.json → 走HTTP/1.1直连 → 卡死。

这不是HTTP/2不支持的问题，而是配置错误引发的协议降级链式反应。验证命令：composer config repo.packagist输出的url字段必须严格匹配https://mirrors.aliyun.com/composer/（含尾斜杠）。

HTTP/2支持与否，从来不是单独开关，而是cURL版本、PHP编译选项、镜像服务端策略、DNS解析质量、甚至Linux内核TCP栈参数共同作用的结果。调优时别只盯着Composer命令行参数，先确认底层网络链路是否真跑在HTTP/2上。