zlib_decode(): data error 根本原因是 PHP zlib 扩展对 ZIP64 或含数据描述符的 ZIP 流解析失败，非网络或磁盘问题；应优先清对应包缓存、关 zlib.output_compression=Off、改 zlib.encode=""，或用 COMPOSER_UNZIP=7zip 绕过内置解压。
zlib_decode(): data error 不是网络超时，也不是磁盘空间不足，而是 Composer 在调用 PHP 的 zlib_decode 函数解压 ZIP 包时，输入数据流损坏或格式不兼容导致的硬性失败。多数情况下，删缓存、换镜像、重试都没用——因为问题出在 PHP 自身 zlib 扩展对某些 ZIP 流（尤其是含数据描述符或 ZIP64 结构的包）的解析逻辑上。
删缓存只是绕过损坏 ZIP，不是根治
Composer 默认复用 ~/.composer/cache/files/ 下已下载的 ZIP 文件。一旦某个包的 ZIP 被截断或校验失败，后续所有 composer install 或 composer update 都会反复加载这个坏文件，直接触发 zlib_decode(): data error。
- 运行
composer clear-cache可清空整个缓存，但耗时长、影响广 - 更精准的做法：定位报错包名（加
-v参数运行可看到具体哪个.zip解压失败），然后手动删掉对应路径，例如：rm -rf ~/.composer/cache/files/laravel/framework/ - 临时跳过缓存：加
--no-cache强制走网络重下，验证是否真为缓存损坏
zlib.output_compression 必须为 Off
PHP 的 zlib.output_compression 配置若为 On、1 或 "1"，会导致 Composer 内部 HTTP 响应流被 PHP 二次压缩，传给 zlib_decode 的是一段嵌套压缩的乱码，必然报错。
- 检查当前值：
php -i | grep "zlib.output_compression"，确认输出是Off（不是0或空字符串） - 修改
php.ini（CLI 配置，非 Web 配置）：zlib.output_compression = Off - 如果用了
zlib.encode（PHP 8.0+），也建议设为空：zlib.encode = ""或直接注释掉 - 改完必须重启 CLI 环境（比如关掉当前终端再新开），
php -v不会体现，要用php -i再确认
用 7-Zip 替代 PHP zlib 解压（Windows / WSL 最稳方案）
Composer 2.2+ 支持通过 COMPOSER_UNZIP 环境变量指定外部解压工具，彻底绕过 PHP 的 zlib_decode。这对 Windows 和 WSL 用户尤其有效——PHP zlib 在这些平台对 ZIP64 支持历来不稳定。
- Windows：安装 7-Zip，确保
7z.exe在系统 PATH 中（cmd 运行7z应有响应） - 执行：
set COMPOSER_UNZIP=7zip && composer install（Windows CMD）或COMPOSER_UNZIP=7zip composer install（WSL/Linux/macOS） - 该设置只影响本次命令；如需持久化，可写入 shell 配置（如
~/.bashrc）或 Windows 系统环境变量 - 注意：不要设成
7z或7za，必须是7zip（Composer 内部硬编码匹配）
别盲目禁用 COMPOSER_DISABLE_ZLIB=1
设 COMPOSER_DISABLE_ZLIB=1 会让 Composer 放弃 ZIP 压缩传输，改用未压缩的 TAR 格式，虽能避开 zlib_decode，但副作用明显：
- 下载体积翻 3–5 倍，国内镜像下极易因超时中断 并不修复根本问题，只是掩盖；下次换环境仍可能复现
- 部分私有仓库或自定义 installer 不支持 TAR，直接报错
- 它绕过的是网络压缩（HTTP
Content-Encoding: gzip），和本地解压zlib_decode是两层逻辑，容易混淆
真正要动的，是 PHP 的 zlib 行为本身，而不是让 Composer “不用 zlib”。
