Composer本身不支持HTTP/3，因其底层CurlDownloader未启用cURL的HTTP/3选项且无配置入口；主流镜像站亦未开启HTTP/3支持，实际收益有限，优化镜像源、代理和缓存更有效。
Composer 本身不支持 HTTP/3
直接结论：Composer install 或 update 命令无法使用 HTTP/3 协议下载包，底层 CurlDownloader 依赖 cURL，而当前主流 cURL 版本（截至 2026 年中）虽已支持 HTTP/3，但 Composer 未启用相关选项，也未暴露配置入口。强行修改源码或 patch cURL 行为风险高、不可维护。
想用 HTTP/3？得换底层 HTTP 客户端
Composer 的网络层是封闭的，但你项目里发 HTTP 请求完全可另起炉灶。关键不是“让 Composer 支持 HTTP/3”，而是「在业务代码中用支持 HTTP/3 的客户端替代默认 cURL 封装」：
-
GuzzleHttp\Client从 v7.5 起支持 HTTP/3，但需手动启用：['curl' => [CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_3]]，且要求 cURL 编译时启用了nghttp3+quictls -
symfony/http-client在 6.4+ 中可通过h3transport 启用 HTTP/3，配置项为'transport' => 'h3'，但同样强依赖底层 cURL 或 PHP 8.3+ 的curl扩展支持 - 纯 PHP 实现（如
amphp/http-client）支持 HTTP/3，但需运行在amphp/amp异步环境中，与传统同步流程不兼容
HTTP/3 实际收益有限，别为它动 Composer
对 Composer 场景而言，HTTP/3 的优势（如连接复用、头部压缩、0-RTT）几乎无法体现：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Composer 下载是短连接、大批量小文件（
packages.json、composer.json、zip 包），非长连接流式场景 - 绝大多数镜像站（阿里云、腾讯云等）尚未开启 HTTP/3 支持，请求会自动降级到 HTTP/1.1
- 启用 HTTP/3 后若服务端不支持，cURL 会静默 fallback，但增加 handshake 开销，反而可能变慢
真正该优化的，是 Composer 的并发与缓存策略
比起折腾 HTTP/3，这些调整立竿见影：
- 通过
COMPOSER_PROCESS_TIMEOUT=300避免大包下载被中断 - 设置
composer config -g repos.packagist.org.allow_ssl_downgrade false强制 HTTPS，避免中间人干扰 - 用
composer install --no-suggest --no-plugins减少非必要元数据请求 - 私有环境部署
satis或toran-proxy，本地缓存全部包，彻底绕过公网传输
HTTP/3 是个好东西，但在 Composer 生态里，它目前只是个纸面特性——真要提速，盯紧镜像源、代理链路和本地缓存，比调协议版本实在得多。
