PHP未编译zlib扩展导致zlib_decode()等函数缺失，php -m无输出且function_exists返回false；必须重新编译并显式添加--with-zlib参数，路径需匹配系统zlib头文件位置。
php -m 里没 zlib 就是没编译进去
不是配置问题，是 PHP 源码编译时压根没加 --with-zlib。这种情况下 zlib_decode()、gzopen() 等函数根本不存在，php -m | grep zlib 输出为空，function_exists('zlib_decode') 返回 false。Composer 安装卡在“Downloading”之后、解压前就崩，报错类似 zlib extension is missing 或直接静默失败。
必须重新编译 PHP，并显式加入：--with-zlib。路径不标准时得补全，例如：
- macOS Homebrew：
--with-zlib=/opt/homebrew/opt/zlib - Linux 多数发行版：
--with-zlib=/usr（头文件通常在/usr/include/zlib.h） - 若系统 zlib 安装在
/usr/local，则用：--with-zlib=/usr/local
只加 --enable-zip 不行——zip 扩展依赖 zlib，没 zlib，zip 加载会失败或功能残缺。
php.ini 里开了 extension=zip 但还是报 zlib 缺失
常见于 Docker 或手动编译环境：CLI 模式用的 php.ini 和 Web 服务器用的不是同一个。先确认 CLI 实际加载的是哪个配置：php --ini。再检查该 php.ini 中是否真启用了 zlib：
- Linux/macOS：
extension=zlib（PHP 8+ 可省略.so） - Windows：
extension=php_zlib.dll - 确保该行未被注释（前面没分号
;）
如果 extension=zlib 已存在但仍不生效，运行 php -r "echo function_exists('gzopen') ? 'OK' : 'FAIL';" 直接验证函数可用性。FAIL 就说明扩展没真正加载，大概率是路径错、so 文件缺失，或与 opcache 冲突。
zlib_decode(): data error 这类错误怎么绕过
这不是 ZIP 文件损坏，而是 PHP 的 zlib 流解析器在处理含数据描述符或 ZIP64 的包时不稳定，尤其在 PHP 8.2+、WSL 或 Windows 下高频出现。堆栈里带 zlib_decode() 就基本能锁定。
优先尝试以下实操步骤：
- 清缓存：
composer clear-cache，再加--no-cache重试 - 关掉 zlib 输出压缩：
zlib.output_compression = Off（注意必须是Off，不是0或空字符串），改完重启 CLI PHP - 禁用 zlib 编码（PHP 8.0+）：
zlib.encode = "" - 最稳方案：装
7z或7zz，确保which 7z有输出，然后运行：COMPOSER_UNZIP=7zip composer install - 临时应急（仅调试）：
COMPOSER_DISABLE_ZLIB=1 composer install，但速度极慢且跳过所有流式校验
ZipArchive::extractTo(): failed to open stream 真因不是 ZipArchive
这个报错表面是“打不开文件”，实际几乎全是权限或磁盘问题。Composer 解压时会在系统临时目录（TMPDIR，Linux/macOS 默认 /tmp，Windows 用 %TEMP%）建子目录并写入中间文件，任一环节失败都会抛这个异常。
排查要点：
- 查磁盘空间和 inodes：
df -h && df -i，/tmp分区满是隐形杀手 - 确认
TMPDIR可写：touch $TMPDIR/test && rm $TMPDIR/test - 换临时目录（推荐）：
export TMPDIR="/mnt/bigdisk/tmp" && mkdir -p "$TMPDIR" && chmod 777 "$TMPDIR" - 注意：
COMPOSER_CACHE_DIR控制的是下载缓存位置，不影响解压过程；只有TMPDIR才管解压时的临时文件
别在没确认 zlib 和 zip 真实可用的前提下，只盯着这个错误调 ZipArchive——它只是表象，底层往往卡在 zlib 流读取或磁盘写入上。
