php原生ziparchive类是最可靠方式，需检查文件存在性、路径权限及http头设置，中文名需转gbk或引导用户用utf-8解压工具，大文件避免内存溢出。
PHP用ZipArchive打包多个文件最稳
直接上结论：PHP原生ZipArchive类是当前最可靠、兼容性最好、控制最细的方式，比exec('zip')或第三方库更少踩坑。它从PHP 5.2起就内置，无需额外安装扩展（只要没被禁用）。
常见错误是调用addFile()前没检查源文件是否存在或路径是否可读，导致ZIP生成成功但里面空文件或漏文件；还有忽略open()返回值，把ZIPARCHIVE::CREATE写成字符串或常量拼错，结果静默失败。
实操建议：
- 先
$zip = new ZipArchive();，再用$res = $zip->open($filename, ZipArchive::CREATE);判断返回值是否为0，非0就别往下走了 - 每个
addFile()前加file_exists()和is_readable()双检，尤其注意相对路径——脚本执行路径不等于Web根目录 - 想往ZIP里放子目录？用
addFile($realpath, 'subdir/filename.txt')第二个参数指定归档内路径，不是自动解析目录结构 - 别在循环里反复
open()/close()，一个ZIP只开一次、批量addFile()、最后close()
中文文件名在ZIP里乱码怎么办
windows解压软件默认用GBK解压，而PHPZipArchive写入时用的是UTF-8原始字节，所以中文名变问号或方块。这不是PHP bug，是ZIP规范本身没强制编码标准，各解压工具自行猜测。
立即学习“PHP免费学习笔记（深入）”；
能用的解法只有两个，且必须二选一：
- 服务端转码：用
iconv('UTF-8', 'GBK//IGNORE', $filename)把中文文件名转成GBK再传给addFile()或addFromString()——但仅限目标用户基本是Windows+国产解压软件（如360压缩、Bandizip） - 客户端兼容：告诉用户用7-Zip、winrar或macos自带归档工具打开，它们默认按UTF-8解析——更通用，但没法强制用户怎么做
- 完全规避：文件名全用英文+下划线，内部用json文件记录原始中文名映射表，适合对一致性要求高的系统
addFromString()比addFile()更适合动态内容
当你需要把数据库导出、API响应、临时生成的PDF等内容直接塞进ZIP，而不是先写到磁盘再读取，addFromString()就是为此设计的。它绕过IO，内存中拼装，快且干净。
注意点很实际：
-
addFromString('report.pdf', $pdf_binary_data)第一个参数是ZIP里的文件名（同样有中文乱码问题），第二个是完整二进制内容，不是路径 - 别把大文件（比如>50MB）整个load进内存再传进去，会OOM；应分块生成+流式写入，但
ZipArchive不支持流式添加，此时得切回addFile()配合临时文件 - 如果内容含NUL字节（比如图片二进制），确保传入的是原始
string，别被JSON decode或trim意外截断
生成完ZIP必须设好HTTP头再输出
生成文件只是第一步，用户点下载链接却看到空白页或xml报错，八成是HTTP响应头没设对。PHP不会自动帮你加Content-Disposition，浏览器就不知道这是附件。
关键三行不能少：
header('Content-Type: application/zip'); header('Content-Length: ' . filesize($zipfile)); header('Content-Disposition: attachment; filename="export_' . date('Ymd_His') . '.zip"');容易漏的细节：
- 输出ZIP前确保没有任何echo、var_dump、bom字符或错误警告，否则ZIP文件头部被污染，解压时报“invalid zip file”或“archive is corrupt”
- 用
readfile($zipfile)输出后记得unlink($zipfile)删临时文件，不然磁盘迟早爆 - 如果用
ob_start()捕获输出再返回ZIP二进制，务必在header()前清空缓冲区，否则headers already sent
最麻烦的其实是权限和路径：Web服务器用户（如www-data）要有ZIP文件所在目录的写权限，同时open_basedir配置不能拦住你写的临时路径。这些不报错，只让open()返回ZIPARCHIVE::ER_OPEN，得自己查日志。