archive/zip批量压缩易卡内存的主因是误将文件全读入内存或未流式处理；正确做法是用io.Pipe实现边读边压，配合filepath.WalkDir构造相对路径、控制并发并确保Close调用顺序。
为什么 archive/zip 默认写法在批量压缩时容易卡住内存
Go 标准库的 archive/zip 本身不缓存整个文件内容，但常见误用是把所有待压缩文件先读进 []byte 再逐个写入 zip.Writer，这会导致内存占用随文件总大小线性增长。更隐蔽的问题是：如果用 os.Open 打开大文件后直接 io.Copy 到 zip.FileWriter，而没控制并发或流式处理，I/O 阻塞会拖慢整体吞吐。
关键点在于：压缩不是 CPU 密集型瓶颈，而是 I/O 调度 + 压缩器缓冲区管理问题。
- 避免一次性
os.ReadFile所有源文件 - 每个
zip.File写入前必须调用Close()，否则后续文件头错位 -
zip.Writer底层用bufio.Writer，默认缓冲区仅 4KB，小缓冲区在大量小文件场景下会频繁 flush，反而降低效率
如何用 io.Pipe 实现边读边压、零内存暂存
真正高效的批量压缩，是让文件读取、压缩、写入磁盘三个阶段尽可能重叠。用 io.Pipe 可以构造一个无缓冲管道，配合 gzip.Writer（注意：zip 本身不压缩，实际压缩由 deflate/gzip 层完成）实现流式处理。
示例核心逻辑：
立即学习“go语言免费学习笔记（深入）”；
pr, pw := io.Pipe()
zw := zip.NewWriter(pw)
go func() {
defer pw.Close()
for _, path := range files {
f, _ := os.Open(path)
w, _ := zw.Create(path)
io.Copy(w, f) // 此处不会等 f 全部读完才写入 zw
f.Close()
}
zw.Close() // 必须调用，否则 zip 尾部结构缺失
}()
// 此时 pr 可传给 os.Create("out.zip").Write 或 http.ResponseWriter
io.Copy(outputWriter, pr)
这个模式下，内存峰值只取决于单个文件的最大块读取量（默认 io.Copy 用 32KB buffer），和文件总数无关。
filepath.WalkDir 遍历时如何安全过滤并保留相对路径
批量压缩常需递归打包某个目录，但 filepath.Walk 已被标记为 deprecated，应改用 filepath.WalkDir。它返回的是 fs.DirEntry，不含完整路径，容易在构造 zip.FileHeader.Name 时出错——比如把 /home/user/a.txt 错写成 a.txt（丢失层级）或 /home/user/a.txt（zip 解压时创建绝对路径，危险）。
正确做法是提前计算根路径前缀，并用 strings.TrimPrefix 截取相对路径：
root := "/data/to/compress"
filepath.WalkDir(root, func(path string, d fs.DirEntry, err error) error {
if !d.IsDir() {
rel, _ := filepath.Rel(root, path)
header, _ := zip.FileHeaderFromFileInfo(d, rel) // 注意：d 不含 ModTime 等，需额外 stat
header.Name = rel // 必须显式赋值，FileHeaderFromFileInfo 不保证设置 Name
w, _ := zw.CreateHeader(header)
// ... 写入内容
}
return nil
})
- 不要依赖
d.Info()获取修改时间，某些文件系统可能不支持，应改用os.Stat(path) -
header.Name中路径分隔符必须为/（即使在 Windows 上），否则部分解压工具无法识别子目录 - 若需跳过
.git或node_modules，在if d.IsDir()分支里return fs.SkipDir
压缩级别与并发控制的实际取舍
zip.Writer 本身不提供压缩级别配置，真正起作用的是底层 flate.Writer（由 zip.FileWriter 内部创建）。可通过反射或封装 zip.RegisterCompressor 替换默认压缩器，但更简单可靠的方式是：用 zip.CreateHeader 创建 *zip.FileHeader 后，手动设置 header.Method = zip.Deflate 并调用 zip.FileHeader.SetModTime 等辅助方法，再传给自定义压缩器。
不过对大多数业务场景，建议放弃微调压缩比，转而控制并发数防雪崩：
- 用
semaphore（如golang.org/x/sync/semaphore）限制同时打开的文件数，避免too many open files - 实测显示：8~16 并发在 NVMe 盘上吞吐最高；超过 32 并发反而因调度开销下降
- 不要为每个文件启 goroutine，而是把文件路径切片分批，每批启动一个压缩任务（复用同一个
zip.Writer）
最易被忽略的一点：zip.Writer.Close() 必须在所有 zip.FileWriter.Close() 之后调用，且只能调用一次——漏掉或重复调用都会导致生成损坏 zip 文件，而这种错误在小文件测试中不易暴露。
