zip_open() 返回 false 怎么查原因
直接看 zip_open() 的返回值没用，它只返回资源或 false，错误信息藏在背后。PHP 不会自动抛异常，得手动补一层检查。
- 先调用
zip_open()，拿到返回值；如果不是资源，立刻用zip_error()+zip_status()查具体错误码 - 常见返回
false的真实原因：文件路径不存在、权限不足（尤其 web 服务器用户如www-data读不到）、文件被占用、ZIP 格式损坏（比如传输中断导致不完整） - 别跳过
is_readable()检查 —— 很多时候不是 ZIP 本身问题，而是 PHP 进程根本打不开这个文件
解压到目录时提示“failed to open stream: Permission denied”
这不是 ZIP 模块的问题，是目标路径写入权限没配对。web 服务进程用户（如 apache 或 www-data）必须对目标目录有 w+X 权限（写 + 执行，后者用于进入子目录）。
- 用
mkdir($path, 0755, true)创建目录时，0755对 owner 是 rwx，但对 group/other 缺少写权限 —— 如果 web 用户不在 owner 组里，就会失败 - 更稳妥的是设成
0775并确保 web 用户属于该目录所属组；或者直接chown www-data:www-data /path/to/unzip - 注意：解压过程会重建 ZIP 内的相对路径（如
assets/js/app.js），所以目标目录必须允许创建多级子目录，不能只给顶层写权限
中文文件名乱码或解压失败
PHP 原生 ZipArchive 类默认按 CP437 解码文件名，而绝大多数中文 ZIP 是 UTF-8 编码。这不是 bug，是历史兼容性设计，但会导致 getNameIndex() 返回乱码、extractTo() 创建错误路径甚至报错。
- 确认 ZIP 文件来源：Windows 打包工具（如 WinRAR、7-Zip）默认用系统编码（GBK/GB2312），macOS / Linux 工具通常用 UTF-8
- 没有通用自动检测方案；稳妥做法是让上游统一用 UTF-8 打包，并在压缩时勾选 “UTF-8 filenames” 选项（7-Zip 支持，WinRAR 需 5.70+）
- 若必须处理旧 ZIP，可用
iconv('GBK', 'UTF-8', $name)尝试转码，但需先判断编码 —— 建议加个简单启发式：如果$name包含连续多个\x81-\xFE字节，大概率是 GBK
大 ZIP 文件解压卡住或内存溢出
ZipArchive::extractTo() 是一次性把整个 ZIP 加载进内存再逐个写文件，对几百 MB 以上的压缩包非常危险 —— 容易触发 memory_limit 中断，或因超时被 nginx/apache 切断连接。
立即学习“PHP免费学习笔记（深入）”；
- 改用流式处理：用
zip_read()+zip_entry_open()逐个读取条目，解压一个写一个，不缓存全部内容 - 设置合理的运行限制：
set_time_limit(0)和ini_set('memory_limit', '512M')，但只是缓解，不能替代流式逻辑 - 生产环境建议加进度反馈：统计已处理的
zip_entry_filesize()占总大小比例，通过 AJAX 或日志输出，避免用户以为卡死
ZIP 解压看着简单，实际卡点全在边界条件：权限模型、编码隐式假设、内存行为、错误反馈缺失。最容易被忽略的是——你永远不知道那个 ZIP 是谁、在哪、用什么软件、什么编码、什么权限打包的。
