Go archive/zip.File.Open 使用后为什么必须关闭返回的文件

我第一次排查 ZIP 批量导入变慢时，最容易忽略的地方不是 zip.OpenReader，而是循环里的 f.Open()。这个方法返回的不是普通的 io.Reader，而是 io.ReadCloser。结论很直接：每次成功打开条目后都要关闭返回值；如果归档来自磁盘，还要在最外层关闭 zip.ReadCloser。

先分清两个需要关闭的对象

zip.OpenReader 负责打开归档本身，返回的 *zip.ReadCloser 代表磁盘上的 ZIP 文件；f.Open 负责打开某一个条目的内容，返回 io.ReadCloser。两者是父子关系，但不是同一个对象。

官方文档把 File.Open 的返回类型定义为 io.ReadCloser，并说明它会透明解压内容、校验校验和。这里的 Close 不是“读完以后可有可无的礼貌动作”，而是这个接口的资源契约。即使某个未压缩条目的关闭实现当前看起来像空操作，也不要把实现细节当成调用约定。

在单个读取函数里完成打开、读取和关闭

最稳妥的边界是“一次函数调用只处理一个条目”。这样 defer 会在当前条目处理结束时执行，而不是等整个 ZIP 批量任务结束。

func readEntry(f *zip.File) ([]byte, error) {
	// File.Open 返回 ReadCloser；无论后续 Read 是否报错，都要释放它。
	rc, err := f.Open()
	if err != nil {
		return nil, fmt.Errorf("打开条目 %q: %w", f.Name, err)
	}
	defer func() {
		// 关闭错误通常不能替代已经发生的读取错误，这里交给上层统一处理。
		_ = rc.Close()
	}()

	// ReadAll 会触发解压和校验；大文件应改用 io.Copy 流式写出。
	data, err := io.ReadAll(rc)
	if err != nil {
		return nil, fmt.Errorf("读取条目 %q: %w", f.Name, err)
	}
	return data, nil
}

这个示例把 Open 错误和 Read 错误分开包装，日志里能直接看到是哪个条目出问题。需要把关闭错误也作为业务失败依据时，可以用命名返回值，在 defer 中仅当主错误为空时写入 err；普通导入任务则至少不要吞掉打开和读取错误。

遍历多个条目时不要把 defer 放在长循环里

下面这种写法看着简短，却会让每轮的 defer rc.Close() 都等到 importZip 返回才执行。条目多、解压器较重或任务运行时间长时，资源峰值会被放大。

func importZip(path string) error {
	// 外层负责归档文件；它的生命周期覆盖整个遍历过程。
	r, err := zip.OpenReader(path)
	if err != nil {
		return fmt.Errorf("打开 ZIP %q: %w", path, err)
	}
	defer r.Close()

	for _, f := range r.File {
		// 目录没有可读取的正文，先跳过，避免把目录错误当成文件内容。
		if f.FileInfo().IsDir() {
			continue
		}
		if _, err := readEntry(f); err != nil {
			return err
		}
	}
	return nil
}

关键不在于“绝对不能在循环里用 defer”，而在于把 defer 放在短生命周期的 readEntry 中。这样每个条目函数返回后立即释放自己的读取器，同时外层 r.Close() 仍然负责归档文件。

用错误边界和检查清单防止资源问题复发

排查时可以按打开、读取、关闭三个边界记录日志，不要看到“文件句柄多”就只改一个 defer。File.Open 还可能因为条目头损坏或压缩算法不支持而失败；读取到末尾时，校验链可能返回校验和错误，所以“读到了部分字节”不等于条目可靠。

• 打开归档后立即安排 r.Close()，不要把它留给调用方猜。
• 每个成功的 f.Open() 都有一个对应的 rc.Close()。
• 大文件使用流式复制，避免为了修复资源问题又制造内存峰值。
• 目录条目先按 FileInfo().IsDir() 判断，普通文件再读取。
• 并发读取可以成立，但每个并发任务都要拥有并关闭自己的读取器。

常见问题

只调用 zip.OpenReader 的 Close 可以吗？

不可以。它只关闭归档级资源，不能替代已经由 f.Open 创建的条目读取器关闭。

条目内容读完后还需要 Close 吗？

需要。读完表示数据消费结束，Close 表示读取器生命周期结束，两者是不同契约。

把 defer rc.Close() 放进循环一定有问题吗？

短循环未必立刻出错，但资源会延迟到外层函数返回。批量处理更适合用独立函数包住单条逻辑，让关闭时机可预测。

记住一条判断就够了：谁调用了 Open，谁就要为返回的可关闭对象安排释放；谁拥有归档文件，谁就负责最后关闭归档。