Go archive/zip File.Open 返回的文件为什么必须 Close

因为 archive/zip.File.Open 返回的不是普通 io.Reader，而是 io.ReadCloser。这个读取器可能包着解压器和 CRC 校验层，成员内容读完或提前结束后都应明确调用 Close。如果压缩包是通过 zip.OpenReader 打开的，外层 ReadCloser 也要单独关闭；两者不是同一个对象。

实用判断：谁调用了 Open，谁就负责关闭返回的读取器；谁拥有磁盘文件，谁就负责关闭外层压缩包。需要确认完整性时，要读到 EOF 并检查读取错误，不能只调用 Close 就当作校验完成。

File.Open 为什么不是普通的 io.Reader

官方 API 将 File.Open 的返回值定义为 io.ReadCloser，并说明它提供 ZIP 成员文件的内容。标准库实现会先定位成员数据，再按压缩方法创建解压器，最后用校验读取器包住解压结果。读取器的 Close 会继续关闭内部解压器，所以它代表一个有结束动作的读取生命周期。

这也是为什么只把它传给一个长期持有的接口、却不保存或关闭返回值，会让代码的资源边界变得模糊。即使某些小文件读取后看不出问题，也不应该依赖实现细节或垃圾回收时机。

读取到 EOF 和直接 Close 有什么区别

如果业务要确认成员内容完整，应该持续读取到 io.EOF，并检查 io.ReadAll 或复制操作返回的错误。校验通常发生在读取过程走到末尾时；提前关闭可以结束读取器，但不能替代“已经读完并完成校验”的证明。

例如，下面的函数把成员读取限制在一个短生命周期内：先处理打开错误，再读取全部内容，最后关闭成员读取器。关闭错误也保留下来，避免真正的释放失败被悄悄吞掉。

func readZipMember(f *zip.File) ([]byte, error) {
	// File.Open 可能创建解压器和校验读取器，成功后必须负责关闭。
	rc, err := f.Open()
	if err != nil {
		return nil, fmt.Errorf("open %s: %w", f.Name, err)
	}

	// 读到 EOF 才能让完整内容校验有机会返回错误。
	data, readErr := io.ReadAll(rc)
	closeErr := rc.Close()
	if readErr != nil {
		return nil, fmt.Errorf("read %s: %w", f.Name, readErr)
	}
	if closeErr != nil {
		return nil, fmt.Errorf("close %s: %w", f.Name, closeErr)
	}
	return data, nil
}

单个成员和批量成员应该怎么关闭

使用 zip.OpenReader 时，外层压缩包和每个成员读取器各有一个关闭点。批量遍历时不要在当前函数里对每个成员都写 defer rc.Close()，否则所有成员都会等到整个函数返回才关闭。把一次成员读取封装到上面的短函数中，或在循环体内显式关闭，更容易控制峰值资源。

func findAndRead(path, wanted string) ([]byte, error) {
	// OpenReader 拥有磁盘文件，函数结束前要关闭外层压缩包。
	r, err := zip.OpenReader(path)
	if err != nil {
		return nil, fmt.Errorf("open archive: %w", err)
	}
	defer func() {
		// 外层 Close 的错误通常只能在这里记录，不能覆盖成员读取错误。
		_ = r.Close()
	}()

	for _, f := range r.File {
		if f.Name != wanted {
			continue
		}
		return readZipMember(f)
	}
	return nil, fmt.Errorf("member %q not found", wanted)
}

如果业务要继续处理多个成员，建议把每个成员的读取放进独立函数，并在函数返回前完成 Close。这样循环只保留当前成员的状态，不会把大量解压器和读取器同时挂到末尾。

OpenReader 和 NewReader 的所有权差异

zip.OpenReader 接收文件名并打开磁盘文件，因此返回的外层 ReadCloser 由调用方负责关闭。zip.NewReader 则接收调用方提供的 io.ReaderAt 和大小，它不会替调用方接管底层对象的关闭责任；但从其中某个 File 调用 File.Open 后，成员读取器仍然有自己的 Close。

最容易写错的三个边界

• 只关外层：关闭 r.Close() 不等于关闭已经创建的成员读取器；成员读取器仍应在自己的作用域内结束。
• 只关成员：如果使用 OpenReader，只关 f.Open 返回值会遗漏磁盘文件的关闭。
• 把 Close 当校验：提前停止读取后直接关闭，不能说明剩余压缩数据和 CRC 已经被完整验证。

当输入来自内存中的 bytes.Reader 时，通常没有需要由 zip.Reader 关闭的外层资源；但这不改变 File.Open 返回值是 ReadCloser 的事实。接口设计上，只要返回值暴露了 Close，就应把它当作调用契约的一部分。

常见问题

成员内容很小，不 Close 也可以吗？

不建议。小文件只是暂时不容易暴露问题，代码仍然缺少明确的资源边界；后续换成压缩成员、批量处理或自定义解压器时，风险会被放大。

读完 EOF 后还需要 Close 吗？

需要。读到 EOF 主要是完成读取和校验，Close 负责结束读取器及内部解压器，两者职责不同。

循环里用 defer 关闭成员可以吗？

可以，但应把循环体放进独立函数，让 defer 在一次成员处理结束时执行；不要让大量成员的 defer 都等到外层批处理函数返回。

结论

File.Open 必须 Close 的根本原因，是它返回了带内部读取生命周期的 io.ReadCloser，而不是一次性拿到的字节切片。正确做法是：OpenReader 的外层关闭一次，每个 File.Open 的成员读取器各自关闭一次；需要完整性时先读到 EOF 并检查错误，再结束读取器。