zlib_decode(): data error 是 php zlib 扩展解析 zip64 或含数据描述符的 zip 流失败所致，非网络或镜像问题；应清缓存、关 zlib.output_compression、设 zlib.encode=""，或用 composer_unzip=7zip 绕过内置解压。
为什么 composer install 报 zlib_decode(): data error
这不是镜像源坏了，也不是网络中断，而是 Composer 下载完 ZIP 包后，PHP 的 zlib 扩展在解压时崩溃。常见于 PHP 8.2+、WSL、Windows 或某些 Alpine 镜像环境，本质是 zlib 对 ZIP64 或含数据描述符（data descriptor）的流解析不稳定。
关键点：这个错误发生在本地解压阶段，和镜像是否启用 Gzip/Brotli 无关——但镜像若同时返回压缩过的 ZIP（如 Content-Encoding: gzip），而客户端又没正确处理双重压缩（ZIP 内部已压缩 + HTTP 层再 gzip），就容易触发 zlib 解码错乱。
- 先确认是否真由 HTTP 压缩引发：加
-vvv运行composer install，看日志里下载 URL 是否带.zip后缀且响应头含Content-Encoding: gzip - 临时绕过：设环境变量
COMPOSER_NO_ZIP=1强制用curl下载而非ext-zip，避免 zlib 解压路径 - 更稳妥做法：禁用镜像的 ZIP 层 Gzip（仅保留 JSON 元数据压缩），因为 ZIP 文件本身已是压缩格式，再套一层 gzip 反而增加解压失败概率
镜像服务端 Gzip 配置踩坑：哪些 MIME 类型必须包含
Nginx 启用 gzip 时若漏掉关键类型，Composer 会收到未压缩的 JSON 元数据（体积翻 3–5 倍），导致超时或内存溢出；但若多加了不该压的类型（如已压缩的 ZIP），又可能让 PHP cURL 解压逻辑混乱。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
Composer 实际依赖的响应体主要是：application/json（packages.json、p2/xxx.json）、text/plain（部分 legacy provider 文件）、application/vnd.php.serialized（私有仓库二进制序列化数据）。
-
必须包含：
application/json、text/plain、application/vnd.php.serialized -
严禁包含：
application/zip、application/x-zip-compressed—— ZIP 包本身已是压缩格式，再 gzip 易引发zlib_decode错误 - 检查方式：用
curl -I -H "Accept-Encoding: gzip" https://mirrors.aliyun.com/composer/packages.json，确认响应头含Content-Encoding: gzip且状态码为200
如何验证当前镜像是否在用 Gzip 而非 Brotli
Composer 客户端不主动声明 Accept-Encoding，完全依赖 cURL 默认行为。PHP 8.0+/Alpine 3.16+ 默认支持 Brotli，但 Windows 上多数旧版 PHP（如 XAMPP、WAMP）只认 gzip。如果镜像返回 br 而客户端不支持，cURL 会静默失败或报 Unsupported encoding type 'br'，最终降级为无压缩传输。
- 查真实请求头：运行
strace -etrace=network composer install 2>&1 | grep connect（Linux/macOS），再用curl -v https://mirrors.aliyun.com/composer/packages.json 2>&1 | grep '^ - 强制走 gzip：在镜像 Nginx 配置中加
gzip_disable "msie6";并确保brotli off;，避免协商出br - CI 环境（如 GitHub Actions）默认用 Ubuntu runner，Brotli 支持较稳；但 Windows runner 或自建 Agent 若用 PHP 7.4，务必关 Brotli，只留 gzip
清缓存时 composer clear-cache 为什么不够
composer clear-cache 只删 ZIP 包和 packages.json 缓存文件，但不会清除已写入 vendor/composer/installed.json 或 composer.lock 中的旧元数据路径。如果镜像刚切换、Gzip 配置刚调优，旧 lock 文件仍按未压缩路径去请求，就会反复失败。
- 必须连带删除：
rm -rf vendor/ composer.lock（项目级）和rm -rf ~/.composer/cache/（全局） - 验证是否生效：运行
composer install --no-cache -vvv 2>&1 | grep "GET https.*json"，确保 URL 是新镜像地址，且后续日志出现Downloading https://.../packages.json而非直接读缓存 - 特别注意 Docker 构建：多层缓存可能保留旧
composer.lock，应在RUN指令前加rm -f composer.lock和rm -rf vendor
gzip_types 配错，就可能让 90% 的失败都卡在 zlib_decode() 这一行。
