Go archive/zip读取 Zip 文件并及时关闭的资源方案

读取 Zip 文件时，真正需要记住的是两个关闭点：zip.OpenReader 打开的归档要关闭，File.Open 返回的条目流也要关闭。最稳妥的写法是让“单个条目读取”成为一个小函数，在函数内用 defer 关闭条目流；归档级关闭则由外层函数负责。这样读取失败或提前返回时，资源边界仍然清楚。

OpenReader 和 NewReader 的关闭责任不是一回事

archive/zip 有两种常见入口。磁盘文件使用 zip.OpenReader(name)，它返回 *zip.ReadCloser，关闭动作最终会让 Zip 文件不能再进行 I/O。已有 io.ReaderAt 和文件大小时，可以使用 zip.NewReader(r, size)；这个 Reader 本身不负责关闭传入对象。

无论采用哪种入口，条目内容都通过 f.Open() 取得一个 io.ReadCloser。所以不要把“归档 Reader 不需要关闭”误解成“条目流也不用关闭”。

先登记归档关闭，再打开条目流

读取磁盘 Zip 时，归档打开成功后立刻登记关闭；之后的文件枚举、条目打开和内容复制都放在这个边界内：

func readZip(path string, want string) ([]byte, error) {
	// OpenReader 拥有磁盘 Zip 的文件句柄，成功后必须由当前函数关闭。
	archive, err := zip.OpenReader(path)
	if err != nil {
		return nil, fmt.Errorf("open zip: %w", err)
	}
	defer archive.Close()

	for _, file := range archive.File {
		if file.Name != want {
			continue
		}
		return readZipEntry(file)
	}
	return nil, fmt.Errorf("entry %q not found", want)
}

这里的 defer archive.Close() 覆盖“找不到条目”和 readZipEntry 返回错误两条路径。示例选择一个名称读取；若业务需要遍历全部条目，也应保持归档关闭位于外层。

File.Open 配合 io.Copy 才是条目级收尾点

条目流不要在循环外共享，也不要假定读到 EOF 就替代了 Close。把它放进单条目函数，既能让 defer 很快执行，也能把读取错误包装在具体文件名上：

func readZipEntry(file *zip.File) ([]byte, error) {
	// File.Open 返回条目级 ReadCloser，函数退出时释放解压读取资源。
	rc, err := file.Open()
	if err != nil {
		return nil, fmt.Errorf("open entry %q: %w", file.Name, err)
	}
	defer rc.Close()

	var buf bytes.Buffer
	// Copy 负责持续读取；archive/zip 会在读取过程中校验条目内容。
	if _, err := io.Copy(&buf, rc); err != nil {
		return nil, fmt.Errorf("read entry %q: %w", file.Name, err)
	}
	return buf.Bytes(), nil
}

File.Open 的返回值是 io.ReadCloser，而不是只读接口。即使 io.Copy 报错，也会先执行关闭动作。生产代码若必须判断关闭失败，可把关闭错误写入命名返回值或在显式收尾时合并记录。

循环读取时，defer 应该放在哪一层

下面这种写法容易让很多条目流一直等到外层函数结束才关闭：

for _, file := range archive.File {
	// 循环里的 defer 绑定外层函数，不会在本轮迭代末尾执行。
	rc, err := file.Open()
	if err != nil {
		return err
	}
	defer rc.Close()
	// 这里只做读取，条目很多时关闭动作会持续堆积。
}

推荐把循环体交给 readZipEntry 这样的小函数，或者在本轮读取结束后显式调用 Close 并保存关闭错误。若改用 NewReader，外部的 bytes.Reader、os.File 仍由调用方管理；只有 File.Open 生成的条目读取器属于本次读取边界。

用一张表确认每个对象的资源边界

另一个容易忽略的边界是压缩包内文件名。本文只讨论读取和关闭；若要落盘解压，还应单独校验 FileHeader.Name 的路径安全，不能直接把它拼到目标目录。

延伸问答

读完条目后还需要调用 Close 吗？

需要。读到 EOF 说明内容读取结束，不等同于释放 io.ReadCloser 的责任。

OpenReader 失败时要 Close 吗？

先检查错误。只有返回成功的归档对象才登记关闭；若同时返回对象和 ErrInsecurePath，应结合业务安全策略决定是否接受该对象，不能无视错误语义。

可以把所有条目的 defer 都留在一个函数里吗？

少量条目可能看不出问题，但大量条目会让关闭延迟到外层函数结束。拆成单条目函数通常更容易控制资源峰值和错误定位。