PHP 8.5不存在，当前最高稳定版为8.3；zip扩展自7.4起默认启用，需确认是否安装并启用，Linux用apt、macOS用Homebrew、Windows修改php.ini启用。
PHP 8.5 没有 zip 扩展 —— 先确认你装的是什么版本
PHP 官方目前（截至 2024 年中）最高稳定版是 8.3，8.4 尚在 RC 阶段，8.5 并不存在。如果你看到“PHP 8.5”，大概率是误传、测试分支或第三方打包版本。这直接决定你能不能用 zip 扩展：标准 PHP 从 7.4 起就默认启用 zip 扩展，但前提是它被编译进 PHP 或动态加载了。
验证方式很简单：
php -m | grep zip
如果没输出，说明扩展没启用；如果报错 Extension 'zip' not found，就得手动处理。
- Linux（apt）：
sudo apt install php-zip，然后重启 Web 服务（如sudo systemctl restart apache2或php-fpm） - macOS（Homebrew）：
brew install php@8.3（自动带 zip），检查php --ini对应的php.ini是否有extension=zip - Windows：打开
php.ini，取消注释;extension=zip→ 改成extension=zip，保存后重启服务器
用 ZipArchive 压缩文件夹最简可行路径
别一上来就写递归遍历 + 判断类型，容易漏掉空目录或权限错误。核心是：先建归档对象，再逐个添加路径，最后关闭。
立即学习“PHP免费学习笔记（深入）”；
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
常见错误现象：ZipArchive::addFile() 返回 false 却没检查；压缩后解压发现路径错乱（比如全堆在根目录）；中文文件名变乱码。
-
ZipArchive::open()必须检查返回值，ZIPARCHIVE::ER_NOZIP或ZIPARCHIVE::ER_READ表示路径/权限问题 - 添加子路径时，第二个参数要显式指定归档内路径，例如：
$zip->addFile('/var/www/a.txt', 'src/a.txt') - PHP 8.0+ 默认使用 UTF-8 文件名编码，但 Windows 解压工具可能不认——若需兼容旧环境，加
$zip->setArchiveComment('UTF-8')无用，得靠iconv()转码后再传入（仅限非 UTF-8 系统 locale）
示例（压缩 ./src 目录到 out.zip）：
$zip = new ZipArchive();
if ($zip->open('out.zip', ZipArchive::CREATE) !== TRUE) {
die('无法创建 ZIP');
}
$iterator = new RecursiveIteratorIterator(new RecursiveDirectoryIterator('./src'));
foreach ($iterator as $file) {
if (!$file->isFile()) continue;
$relPath = substr($file->getPathname(), strlen('./src/') + 1);
$zip->addFile($file->getPathname(), $relPath);
}
$zip->close();
ZipArchive::extractTo() 解压失败的三个高频原因
不是所有 ZIP 都能直接解压成功。即使 $zip->open() 返回 TRUE，extractTo() 仍可能静默失败或只解出部分文件。
- 目标目录不存在且不可写：必须提前
mkdir($dest, 0755, true)，不能依赖extractTo()自动创建父级 - ZIP 内含绝对路径（如
/etc/passwd）或上层路径（../config.php）：PHP 8.0+ 默认开启ZipArchive::EMULATION防护，但老 ZIP 可能触发ZipArchive::ER_MEMORY错误——建议用$zip->getFromName()逐个读取再file_put_contents()写入 - 文件时间戳超出系统支持范围（如 Unix 时间戳
0或极大值）：某些 Linux 内核会拒绝设置非法 mtime，导致extractTo()报Warning: ZipArchive::extractTo(): Invalid argument，此时加@抑制警告，或改用流式提取
大文件压缩 / 解压时内存和超时的实际控制点
ZipArchive 是内存操作，不是流式处理。压缩 500MB 目录时，峰值内存可能达 1.2GB；解压同理。PHP 的 memory_limit 和 max_execution_time 很容易成为瓶颈。
- 压缩前调低开销：
ini_set('memory_limit', '1G')、set_time_limit(0)（注意 CLI 和 Web SAPI 行为不同） - 避免一次性
addGlob()或addPattern()加载太多文件——它们内部仍会遍历并缓存元数据，不如手写迭代器 +yield控制节奏 - 真要处理 GB 级 ZIP，别硬扛：用
exec('zip -r out.zip src/')调用系统zip命令（确保安全过滤路径），或换phar扩展（支持流式写入，但不兼容标准 ZIP 工具）
真正麻烦的不是语法，是 zip 文件本身结构不规范、跨平台编码混杂、以及 PHP 运行环境对底层 libzip 版本的隐式依赖——这些不会报错，但会让同一段代码在开发机和生产机表现不同。
