zlib_decode(): data error 根本原因是 PHP zlib 扩展对 ZIP64 或含数据描述符的 ZIP 流解析失败,非网络或磁盘问题;应优先清对应包缓存、关 zlib.output_compression=Off、改 zlib.encode="",或用 COMPOSER_UNZIP=7zip 绕过内置解压。

Composer报错zlib_decode(): data error处理与排查指南

zlib_decode(): data error 这个报错,看着像是网络超时或者磁盘写不动了,但实际压根不是那回事。它是 Composer 在调用 PHP 内置的 zlib_decode 函数解压 ZIP 包时,发现输入的数据流本身坏了或者格式不兼容——直接硬拒绝。最坑的是,你删缓存、换镜像、重试好几遍,往往还是同一张脸,因为罪魁祸首是 PHP 自己的 zlib 扩展在处理某些 ZIP 流(尤其带数据描述符或 ZIP64 结构的包)时,解析逻辑上就翻车了。

删缓存只是绕过损坏 ZIP,不是根治

Composer 默认会把下载好的 ZIP 文件缓存到 ~/.composer/cache/files/ 下面。一旦某个包的 ZIP 被截断或者校验失败,后面每次 composer installcomposer update 都会反复加载这个坏文件,一路撞到 zlib_decode(): data error 上。

zlib.output_compression 必须为 Off

PHP 的 zlib.output_compression 配置如果被设成了 On1"1",Composer 内部收到的 HTTP 响应流就会被 PHP 额外压缩一次。结果传给 zlib_decode 的是一段被嵌套压缩的乱码,不报错才怪。

用 7-Zip 替代 PHP zlib 解压(Windows / WSL 最稳方案)

Composer 2.2 及以上版本支持通过 COMPOSER_UNZIP 环境变量指定外部解压工具,这样就能彻底绕过 PHP 的 zlib_decode。对 Windows 和 WSL 用户来说尤其管用——PHP zlib 在这些平台上对 ZIP64 的支持一直不太稳定。

别盲目禁用 COMPOSER_DISABLE_ZLIB=1

有人可能会遇到 COMPOSER_DISABLE_ZLIB=1 这个选项,设了以后 Composer 会放弃 ZIP 压缩传输,改用未压缩的 TAR 格式。虽然能避开 zlib_decode,但副作用相当明显:

所以真正要动的是 PHP 的 zlib 行为本身,而不是让 Composer “不用 zlib”。

本文转载于:https://www.php.cn/faq/2347749.html 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。