archive/zip不能直接用于大文件分片压缩，因其writer依赖连续写入并自动追加central directory，而分片需每片独立可解压；必须改用流式切块、独立压缩、自定义元信息管理。
为什么 archive/zip 不能直接用于大文件分片压缩
因为 archive/zip 的 Writer 设计上依赖连续写入，它会在写入末尾自动追加 central directory，而分片压缩要求每个片段是独立、可单独解压的 zip 文件（或自定义格式），否则无法并行写入、也无法按需下载解压某一片段。强行切分会导致 zip 结构损坏，unzip 报错 invalid zip file 或 missing central directory。
所以必须绕过标准 zip 封装逻辑，改用裸数据流分片 + 单独压缩 + 自定义元信息管理。
- 分片不等于“把一个 zip 拆成几段”，而是“把原始文件切块 → 每块独立压缩 → 每块存为完整压缩单元”
- 每片需携带自己的校验和（如
sha256）、原始偏移、长度，否则无法还原顺序和完整性 - 不要尝试用
zip.Writer.RegisterCompressor改变压缩方式——它不解决分片问题，只影响单个文件内的压缩算法
用 io.Pipe + gzip.Writer 实现无内存压力的单片压缩
大文件分片压缩最怕 OOM，关键是要避免把整块读进内存再压缩。正确做法是用管道流式处理：一边 io.Copy 从文件切片读，一边写入 gzip.Writer，后者底层自动缓冲并压缩输出。
// 示例：压缩第 i 片（起始 offset，长度 size）
pr, pw := io.Pipe()
go func() {
defer pw.Close()
f, _ := os.Open("bigfile.bin")
defer f.Close()
f.Seek(offset, 0)
io.Copy(pw, io.LimitReader(f, size)) // 严格限制只读 size 字节
}()
gz := gzip.NewWriter(pr)
_, _ = io.Copy(gz, pr) // 压缩流式进行
gz.Close() // 必须显式 close，否则尾部 gzip header 不完整
-
io.LimitReader是安全边界，防止因文件截断或多线程竞争导致读超界 -
gzip.Writer.Close()不可省略——它会 flush 压缩器并写入 EOF 标记，缺失则解压时提示unexpected EOF - 别用
gzip.NewWriterLevel(pw, gzip.BestSpeed)直接传管道写入器，这会让压缩器阻塞在未就绪的pw上；必须用io.Pipe解耦读写协程
并发控制与分片命名要带可排序的序号
用 sync.WaitGroup + semaphore 控制 goroutine 数量，避免打开过多文件句柄或耗尽内存。分片名必须用固定宽度数字（如 part_0001.gz），否则 ls 或程序遍历时顺序错乱，导致还原失败。
- 推荐最大并发数设为
runtime.NumCPU()，磁盘 I/O 密集型场景下超过 8 通常收益递减 - 分片大小建议 64–256 MiB：太小增加元数据开销和文件系统压力；太大削弱并行度和恢复粒度
- 文件名中避免使用时间戳（如
part_20240520_123456.gz），它无法反映逻辑顺序；用part_%04d.gz格式最稳妥 - 写完每个分片后，立刻调用
os.Chmod(path, 0444)防止被意外覆盖（尤其在重试逻辑里）
还原时必须校验再拼接，不能信任文件系统顺序
即使用了有序命名，filepath.Glob("part_*.gz") 返回的切片顺序也不保证跨平台一致（Windows/Linux 对大小写和编码处理不同）。必须提取序号并显式排序；更关键的是，每个分片解压前必须验证 sha256 和长度，否则损坏的分片会污染整个还原结果。
// 还原伪代码关键段
files := findPartFiles("part_*.gz") // 自定义函数，返回 []struct{idx int; path string}
sort.Slice(files, func(i, j int) bool { return files[i].idx
<p>最容易被忽略的一点：gzip 压缩后的分片，其原始字节长度 ≠ 解压后长度。还原时必须记录每个分片对应的「原始偏移」和「原始长度」，而不是压缩后文件大小——这个元数据必须在压缩阶段就写入 sidecar JSON 或头部 magic bytes，否则无法对齐还原位置。</p>golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
