深入Composer镜像协议：如何实现Metadata的流式在线压缩-composer-PHP中文网

composer metadata 不能直接 gzip 流式压缩，因为 v2 协议要求 json 文件支持 http range 请求以实现随机访问和字段跳转，而流式 gzip 会破坏该能力，且客户端默认不处理 gzip 编码，强行启用易引发解析 panic；官方镜像仅对 zip 包压缩，元数据保持明文。

深入composer镜像协议：如何实现metadata的流式在线压缩

Composer Metadata 为什么不能直接 gzip 流式压缩？

因为 Composer 的元数据协议（v2）要求客户端按需解析 packages.json 和分片 provider-*.json，而这些文件在传输过程中必须保持 JSON 结构完整、可随机访问——gzip 流式压缩会破坏 HTTP range 请求能力，导致 composer install --prefer-dist 在校验包完整性时无法跳转到特定字段（如 dist.shasum 或 versions 数组起始位置）。

更关键的是：Composer 客户端（v2.9.6+）默认不启用 Accept-Encoding: gzip，除非服务端明确在响应头中返回 Content-Encoding: gzip 且 JSON 内容未被修改。一旦你用 nginx 的 gzip on 粗暴启用，可能触发客户端解析 panic（如 json: cannot unmarshal object into Go struct field ...）。

官方镜像站（如阿里云）从不 gzip 元数据文件，只对静态 ZIP 包启用压缩
composer show 和 composer update --dry-run 的调试输出里，能看到实际请求的 Content-Length 和 Content-Type: application/json，但无 Content-Encoding
若强行开启流式压缩，需同步修改 Composer 源码中的 Composer\Package\Loader\RootPackageLoader，代价远高于收益

metadata-minifier 是怎么做到“无损压缩”的？

composer/metadata-minifier 不是 HTTP 层压缩，而是对 Composer 运行时生成的元数据快照（如 vendor/composer/installed.json）做结构化精简：移除注释、合并重复字段、扁平化嵌套数组、用数字索引替代长字符串键名（如把 "name" → 0, "version" → 1），再用标准 JSON 库序列化。

它不碰镜像服务端的 packages.json，只处理本地已下载的元数据副本；因此和镜像协议完全解耦，也无需服务端配合。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

压缩后体积通常减少 30%~50%，但仍是合法 JSON，json.Unmarshal 可直接解析
它不改变字段语义，只是重映射 key 名，所以不影响 composer install 行为
不能用于在线流式场景：它需要完整加载原始 JSON 到内存，再写回新文件——不适合高并发元数据验证引擎

想实现真正的流式在线压缩，该在哪一层动手？

只能在反向代理层（如 Nginx / Envoy）做 conditional gzip，且必须满足三个硬约束：

只对 Accept: application/json 且 User-Agent 包含 composer/ 的请求启用压缩
响应头必须显式设置 Vary: Accept-Encoding, User-Agent，否则 CDN 缓存会混用压缩/非压缩版本
必须禁用 gzip_vary off 和 gzip_http_version 1.0，确保 HTTP/2 下仍生效
最关键：所有 provider-*.json 必须预计算并缓存其 gzip 版本（因 SHA256 校验依赖原始字节），不能动态压缩——否则 sha256(provider.json) ≠ sha256(gzip(provider.json))，签名验证失败

也就是说，“流式”在这里是伪命题：Metadata 的完整性校验和分片结构决定了它必须以确定性字节流交付，而非边压边传。

生产环境更值得投入的优化点

比起折腾流式压缩，真正影响 Composer 镜像性能的瓶颈在 DNS、TLS 和连接复用——尤其当你并发拉取数百个 provider-*.json 时。

用 http.Client 自定义 Transport，开启 MaxIdleConnsPerHost 和 IdleConnTimeout，避免 fd 耗尽
集成 github.com/miekg/dns 实现 DNS 缓存，绕过 Go 默认阻塞式解析
Provider URL 中的 {hash} 占位符必须提前替换完成，否则每个 goroutine 都要重复计算，拖慢整体吞吐
404 响应不能全丢弃：要区分是 vendor 不存在（合法），还是上游镜像故障（需告警），否则元数据缺失问题会被静默掩盖

Metadata 的“压缩”本质是减少传输量，但它的价值远不如保证每个 provider-*.json 的 SHA256 可被原子校验来得关键——后者才是供应链安全的底线。