最可靠方式是用PHP自带ZipArchive类打包目录，需显式添加空目录、处理相对路径、校验压缩包完整性，并优先优化原始文件而非盲目调高压缩级别。
PHP 用
压缩文件夹最可靠
直接用 PHP 自带的
类打包整个目录，是减少文件夹体积最稳妥的方式。它不依赖外部命令（如
），跨平台兼容性好，且能精细控制是否跳过某些文件或目录。
常见错误是直接递归读取目录后手动拼 ZIP 格式字节——这极易出错，也不支持中文路径、空目录等边界情况。必须用
显式添加空目录，否则压缩包里会丢失它们。
实操建议：
先调用
，检查返回值是否为 0，否则说明写入失败（如权限不足或磁盘满）
遍历目录时用
+
，跳过
、
和
等隐藏目录
对每个
对象，用
，其中
需手动去掉源根路径前缀，否则压缩包内路径过深
压缩大目录前建议设置
，避免超时中断
压缩率不够高？别硬改
的 level 参数
的
和
不接受压缩级别参数；它的底层 zlib 压缩等级固定为 6（中等）。想提升压缩率，得换方案。
立即学习
“
PHP免费学习笔记（深入）
”；
更现实的做法是：先用
打包，再用系统
命令重压。例如 Linux 下执行：
。但注意：
是必须的，否则可能变成 ZIP64 或其它不兼容格式；
仅对文本类内容有效，对已压缩文件（如 JPG、PNG、MP4）几乎没用，反而拖慢速度。
容易踩的坑：
Windows 上
命令默认不存在，需确认安装了 Info-ZIP 或 Git Bash 的工具链
用
时未检查返回码，导致“看似成功”但实际没重压
误以为提高 level 能压缩图片/视频——其实应先用专用工具（如
）优化原文件，再打包
删除原始文件前务必验证压缩包完整性
压缩完成不等于可用。很多脚本在
返回
后就直接
，结果发现压缩包打不开——因为
只表示写入完成，不校验数据有效性。
安全做法是立即用
重新打开并尝试读取一个内部文件头：
更严格的场景（如备份系统），应额外计算压缩包的
并与预期比对，或用
命令做完整测试。
小文件多的目录，压缩前先合并再压更省空间
成百上千个小 PHP/JS/CSS 文件单独存进 ZIP，元数据开销可能占到总大小的 10%–20%。这时与其强压，不如先合并。
例如把
合并为
，再压缩。PHP 中可用
循环读取+换行分隔，注意保留 SourceMap 注释（
）位置，避免破坏调试能力。
但要注意：
合并不能破坏执行顺序（如依赖关系），需按业务逻辑排序，不能只按字母序
HTML/PHP 中引用路径要同步更新，否则上线即 404
合并后文件若超过 10MB，某些老旧 ZIP 工具可能无法解压（ZIP32 限制），此时应分卷或放弃合并
真正影响体积的从来不是 ZIP 算法本身，而是原始文件是否冗余、是否已压缩、路径是否合理——压缩只是最后一道工序，别让它承担不该承担的事。
ZipArchiveZipArchivesystem('zip')ZipArchive::addEmptyDir()$zip->open($filename, ZipArchive::CREATE)RecursiveIteratorIteratorRecursiveDirectoryIterator....gitSplFileInfo$zip->addFile($file->getPathname(), $relativePath)$relativePathset_time_limit(0)ZipArchiveZipArchiveaddFile()addFromString()ZipArchivezipexec("zip -r -Z deflate -9 {$filename} {$filename}")-Z deflate-9zipexec()jpegoptim$zip->close()truerrmdir()close()ZipArchive::open()if ($zip->open($filename) === TRUE) {
$stat = $zip->statName('index.php'); // 假设知道有个关键文件
$zip->close();
if ($stat !== false) {
// 确认可读，才删原目录
rrmdir($sourceDir);
}
}md5_file()zip -T/assets/js/*.jsall.jsfile_get_contents()//# sourceMappingURL=...