root package（即项目根目录的composer.json）不参与镜像压缩，因其为本地磁盘文件，不通过http请求传输；镜像压缩仅作用于远程响应体，如packages.json、p2/包名.json及dist zip包。
Composer 镜像源不压缩 root package 本身——它只压缩元数据（如 packages.json、provider-*.json）和 ZIP 包，而 root package 的 composer.json 是本地文件，不走镜像传输流程。
为什么 root package 不参与镜像压缩
root package 指的是你当前项目根目录下的 composer.json，它从不通过 HTTP 请求从镜像源下载。所有镜像压缩逻辑（Gzip/Brotli）只作用于远程响应体：比如 https://mirrors.aliyun.com/composer/packages.json 或 https://mirrors.tencent.com/composer/p2/monolog/monolog.json 这类由 Composer 客户端主动发起的 HTTP GET 请求。
这些请求返回的 JSON 内容体积大（常达 200–500KB），压缩后可减少 60%+ 传输量；而你的本地 composer.json 是直接读取磁盘文件，不存在“下载”和“解压”环节。
- 执行
composer install时，root package 的composer.json被解析为依赖声明起点，不发任何网络请求 -
composer update中涉及的版本计算、SAT 求解，全部基于本地文件 + 远程元数据，root package 自身不被序列化上传或压缩下发 - 即使你配置了私有镜像源，它也不会代理或重写你项目根目录下的任何文件
镜像实际压缩哪些内容
镜像源只对三类响应启用 Gzip/Brotli 压缩：
-
packages.json（顶层索引，含所有 provider 映射） -
p2/vendor/name/version.json（单包精确元数据，含 dist/source 下载地址与 hash） -
distZIP 包本身（如https://.../monolog/monolog/2.13.0/monolog-monolog-2.13.0-zip-9a8b7c.zip）
注意：provider-*.json（如 provider-laravel~10.0.json）也属于被压缩对象，但它的存在依赖镜像同步进度——若镜像尚未拉取该分片，请求直接 404，连压缩机会都没有。
验证是否启用压缩：用 curl -I https://mirrors.aliyun.com/composer/packages.json 查看响应头，应含 Content-Encoding: gzip 或 br；若无，说明该镜像未开启服务端压缩（极少见，但部分私有 Satis 实例可能遗漏配置）。
容易踩的坑：误以为 root package 被“镜像缓存”或“压缩下发”
常见误解是：改了全局镜像后，composer.json 里的 require 字段会从镜像拉取校验。其实不会——它只影响后续对 monolog/monolog 这类依赖包的元数据查询路径。
- 如果你在
require里写了不存在的包名，报错发生在本地解析阶段，不触发任何镜像请求 - 如果写了合法包名但镜像没同步到对应
p2/...文件，错误是Could not fetch ...，此时压缩与否已无关紧要——根本没响应可解压 - 某些 CI 环境中，
composer install卡住，排查方向应是镜像 URL 是否带/、packagist.org是否被正确禁用，而非怀疑 root package 被“压错格式”
真正需要关注压缩兼容性的，是 PHP+cURL 运行环境：旧版 Windows PHP（如 7.4.x with libcurl 7.54）不支持 br，遇到 Brotli 响应会直接失败；而 Gzip 兼容性无死角。所以国内主流镜像（阿里云、腾讯云）默认同时提供两种编码，由客户端协商决定——但这套逻辑跟 root package 毫无关系。
