archive/zip不支持并发写入，因zip.Writer内部结构强依赖写入时序，多goroutine操作会破坏文件头、中央目录等关键结构，导致解压失败；正确做法是读取并发、写入串行，用channel协调多个reader goroutine与单个writer goroutine。
archive/zip 不支持并发写入，强行多 goroutine 调用同一个 zip.Writer 会导致 ZIP 文件损坏——解压时常见 zip: not a valid zip file 或中央目录丢失。真正可行的并发压缩，是「读取并发 + 写入串行」，不是「压缩并发」。
为什么不能让多个 goroutine 直接往 zip.Writer 里写
zip.Writer 内部维护文件头、本地文件条目、数据区、中央目录和校验和，所有结构强依赖写入顺序。并发调用 CreateHeader() 或 io.Copy() 会破坏这些时序关系，结果不可预测：
- 中央目录写在末尾，但多个 goroutine 可能同时尝试更新它
- 每个
zip.FileHeader的偏移量（Header.Offset）由写入位置动态计算，竞态下值错乱 - 未加锁的缓冲区（如
zw.w底层io.Writer）被并发修改，触发 panic 或静默损坏
正确做法：单 writer goroutine + 多 reader goroutine
把 I/O 密集型的文件读取并行化，CPU 密集型的 ZIP 写入保留在单个 goroutine 中，用 channel 桥接两者：
- 启动固定数量的 worker（比如 4–8 个），每个打开一个文件、读取内容（或传递
*os.File）、发送到chan *fileTask - 单独一个 writer goroutine 从该 channel 接收任务，调用
zw.CreateHeader()→io.Copy()→ 立即file.Close() -
zw.Close()必须在所有文件写完后、且仅调用一次——它负责写入最终中央目录 - 任务结构体建议包含
SrcPath、Header（已处理好Name和Method）、Content（或Reader），避免在 channel 中传未复制的[]byte
协程池比裸开 goroutine 更靠谱
直接 for _, p := range files { go addFileToZip(zw, p) } 是高危操作，容易触发系统限制：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
EMFILE错误：超出ulimit -n（默认常为 1024），大量os.Open()失败 - 磁盘随机读激增：数百个 goroutine 同时 seek 不同文件，吞吐反而暴跌
- 内存堆积：
*os.File+ 缓冲区未及时释放，OOM 风险陡升 - 推荐用带缓冲的
chan string当任务队列，worker 数控制在 4–12（视 SSD/HDD 和 CPU 核心数调整）
大文件（>100MB）要额外注意
哪怕只是单个大文件参与归档，也不能直接 io.Copy(zw, file) —— 它不带缓冲，可能卡住或吃光内存：
立即学习“go语言免费学习笔记（深入）”；
- 必须套一层
bufio.NewReader(file)，并设置合理Size（如 1MB） - 若文件本身需预处理（加密、缩略图生成），应在 reader goroutine 中完成，再传给 writer
-
zip.FileHeader.UncompressedSize64在大文件场景下必须显式设对，否则部分解压工具报错 - 别用
zip.FileInfoHeader(fi)直接构造 header：它不处理 Windows 路径（含\或C:），要用filepath.ToSlash()清洗Name
zw.Close() 调用时机准确、文件句柄及时关闭，其余全是 I/O 调度问题——而那是协程池和 buffer 控制的事。 
