Go archive/zip逐项读取压缩包并控制内存占用的方法

处理用户上传的 ZIP 时，最容易出现的误区是把每个条目都交给 io.ReadAll。压缩包里的一个小文件可能解压成很大的内容，循环中再叠加多个临时切片，内存峰值就会随着输入失控。更稳妥的做法是用 archive/zip 逐项打开文件，把解压流直接写入目标，并用“文件头预判 + 流式探测”限制单文件大小。

核心方案是：先检查 UncompressedSize64，再用 File.Open 和 io.CopyN 流式复制；复制刚好达到上限时额外读取一个字节，确认条目是否真的超限。

官方文档：https://pkg.go.dev/archive/zip

先把 ZIP 句柄和条目边界管住

zip.OpenReader 返回的 ReadCloser 既负责归档读取，也需要在函数结束前关闭。打开成功后遍历 r.File，目录条目不需要解压；文件名则要当作不可信输入，至少拒绝绝对路径、.. 回退和反斜杠。这样可以避免后续拼接输出目录时把条目写到预期目录之外。

func readZip(path string, dst io.Writer, maxBytes int64) error {
	// 打开归档后由当前函数负责关闭底层文件句柄。
	r, err := zip.OpenReader(path)
	if err != nil {
		return fmt.Errorf("open zip: %w", err)
	}
	defer r.Close()

	for _, f := range r.File {
		// 目录没有正文，跳过解压；文件名必须保持本地相对路径。
		if f.FileInfo().IsDir() {
			continue
		}
		if !filepath.IsLocal(f.Name) || strings.Contains(f.Name, `\`) {
			return fmt.Errorf("unsafe entry path: %q", f.Name)
		}
		if err := copyEntry(dst, f, maxBytes); err != nil {
			return fmt.Errorf("entry %q: %w", f.Name, err)
		}
	}
	return nil
}

如果业务需要把每个条目写入不同文件，dst 应在循环内按安全后的相对路径创建；示例把它抽象成一个 io.Writer，重点展示读取和限制逻辑。不要让多个条目共用同一个输出文件，除非你明确设计了拼接格式。

用元数据预判，再用流式复制兜底

FileHeader.UncompressedSize64 是解压后尺寸的第一道信号。它小于等于上限时才打开条目，可以省掉对明显异常文件的解压；但真正的保护仍要放在读取环节，因为输入可能来自不可信上传，读取过程中还要处理校验错误和短读。

func copyEntry(dst io.Writer, f *zip.File, maxBytes int64) error {
	// 先用 ZIP 头中的解压尺寸拦截明显超限条目。
	if maxBytes  0 {
		return fmt.Errorf("entry exceeds limit %d", maxBytes)
	}
	if readErr != nil && !errors.Is(readErr, io.EOF) {
		return fmt.Errorf("probe data: %w", readErr)
	}
	return nil
}

上面的示例用 io.LimitReader 控制写入最多为 maxBytes，再探测一个字节区分“刚好”和“超出”；io.CopyBuffer 让每次复制复用固定容量。生产代码还应检查 Close 的错误是否需要上报。

为什么不能只相信 UncompressedSize64

元数据检查解决的是“提前拒绝”，不是“读取安全”。文件头中的尺寸适合做快速门禁，真正的数据流仍可能在解压、校验或自定义处理时返回错误。因此要把条目读取放在 File.Open 之后，并把返回错误包装上条目名。另一方面，File.Open 会透明解压并校验内容，不能把它等同于读取压缩字节；需要原始压缩流时才考虑 OpenRaw，但这不适合普通的解压处理。

把单文件限制扩展成归档级策略

单文件上限只能防住一个巨大条目。批量上传还应增加条目数上限和总解压字节数上限：每成功写入一段就累计总量，超过归档级阈值立即停止；处理目录条目时也要计数。若业务必须保留多个结果，建议先写到隔离临时目录，全部条目成功后再提交到最终目录，避免半个归档已经对外可见。

最小的验收清单是：一个小文件能正常读完；一个大小恰好等于上限的文件能成功；超过上限的文件不会多写一个字节；损坏条目能返回错误；带 ../ 或反斜杠的名称会被拒绝；归档关闭和条目关闭都能执行。

常见问题

为什么不用 io.ReadAll(f.Open())？

它会把解压后的完整内容放入内存，输入大小一旦失控，峰值就不再由固定缓冲区决定。只有在已知条目很小且确实需要完整字节切片时才适合使用。

UncompressedSize64 小于限制就一定安全吗？

不一定。它只是元数据预判，读取仍可能遇到校验错误、损坏数据或业务处理超时，所以必须保留流式限制和错误处理。

达到上限的文件为什么还要再读一个字节？

因为复制函数无法仅凭“写满上限”判断源流是否刚好结束。额外读取一个字节可以区分恰好达到上限和实际还有剩余内容，且不会把多出的字节写入目标。

把 ZIP 处理拆成路径检查、元数据预判、流式复制和归档级统计四层，既能控制内存，也能让失败原因落到具体条目。对外部上传输入，真正可靠的边界从来不是某一个字段，而是“拒绝明显超限 + 读取时不越界 + 失败不提交”的组合。