composer不支持http/2 server push，因其为单次拉取式cli工具，无长连接与推送接收能力；提速关键在确保镜像url末尾带斜杠、刷新元数据缓存、优化dns/tls连接。
HTTP/2 Server Push 不能用于预推 Composer 镜像的元数据，因为 Composer 客户端根本不支持接收或处理 Server Push 流。
Composer 的网络请求是单向 CLI 发起的，不维持 HTTP/2 连接
Composer 运行在命令行下，每次 composer install 或 composer update 都是一次性发起若干独立 HTTP 请求（如 GET /packages.json、GET /p/monolog/monolog.json），请求结束即断开连接。它没有长连接、没有响应监听机制，更不会解析 Link: rel=preload 响应头或接受服务端主动推送的数据流。
Server Push 是为浏览器这类“持续监听响应”的客户端设计的，而 Composer 是纯拉取式工具——它只认状态码 + 响应体，其余一概忽略。
- 即使镜像源（如阿里云、腾讯云）后端启用了 HTTP/2 + Server Push，Composer 也完全感知不到，更不会缓存或使用推送内容
-
curl -I --http2能看到 HTTP/2 响应，但那是 curl 自己处理的；Composer 底层调用的 cURL PHP 扩展不会把推送流暴露给上层 PHP 逻辑 - 所有“预推元数据”类需求，在 Composer 架构里只能靠客户端主动轮询或缓存优化，无法由服务端干预
真正影响元数据加载速度的，是 packages.json 的缓存与重定向链
你感觉“元数据慢”，大概率不是协议瓶颈，而是以下两个可实操点：
- 镜像 URL 缺少结尾
/：比如配成https://mirrors.aliyun.com/composer（无斜杠），Composer 拼路径会变成https://mirrors.aliyun.com/composerpackages.json→ 404 → 自动 fallback 到官方源 → 全程降级走 HTTP/1.1，且可能超时 - 本地缓存未刷新：
composer update默认复用最多 15 分钟的packages.json，新包发布后立刻composer update vendor/name会查不到——必须加--refresh或手动清~/.composer/cache/repo/https---mirrors.aliyun.com-composer/
想提速？别碰 Server Push，做这三件事
Composer 元数据加载快不快，只取决于三件事：DNS 解析是否稳、TCP/TLS 建连是否复用、HTTP 响应体是否小。Server Push 对这三者均无增益。
- 确认镜像地址带尾斜杠：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 强制刷新元数据：
composer update --refresh（≥2.5）或删对应 repo 缓存目录后重试 - 验证是否真卡在 HTTP 层：
curl -w "@curl-format.txt" -o /dev/null -s https://mirrors.aliyun.com/composer/packages.json，看 time_namelookup / time_connect 占比——若 DNS 或建连耗时高，换 DNS 或加export COMPOSER_NO_TLS=1（仅内网）测基线
Server Push 是个浏览器场景专用机制，硬套到 CLI 工具上不仅无效，还会误导排查方向。Composer 的性能瓶颈永远在线路、缓存和配置细节里，不在协议特性上。
