Go flate.NewReader 返回的 ReadCloser 用完后怎么关闭

用 flate.NewReader 解压数据时，返回值的静态类型是 io.ReadCloser。正确做法是：把它当作解压层资源，在读取结束或函数返回前调用 Close；如果传入的底层对象本身也实现了 io.Closer，例如文件、网络连接或管道，还要由调用方另外关闭底层对象。两层资源不要只关闭其中一层。

最稳妥的收尾顺序是“先结束 flate 解压层，再结束底层输入”。flate.Reader.Close 不会替你关闭传入的 io.Reader，而底层输入的关闭错误也不能被忽略。

官方文档：https://pkg.go.dev/compress/flate

官方源码：https://go.dev/src/compress/flate/inflate.go

先分清 flate 层和输入层

NewReader 接收的是 io.Reader，返回的是 io.ReadCloser。这两个接口看起来只差一个 Close，但代表的对象不同：传入对象提供压缩字节，返回对象负责把这些字节解码成未压缩数据。

官方实现里，解压器的 Close 只检查自身的解码状态并返回错误；它不会对传入的普通 io.Reader 做类型断言后替你调用 Close。因此，底层输入是不是可关闭资源，不能靠 flate 猜测。

最小场景：读取结束后关闭两层

如果压缩数据来自文件，可以把文件和 flate 读取器分别保存。下面的示例把读取错误、解压层关闭错误和文件关闭错误分开处理，便于定位到底是哪一层收尾失败。

package main

import (
	"compress/flate"
	"errors"
	"fmt"
	"io"
	"os"
)

func readCompressedFile(path string) (_ []byte, err error) {
	// 文件由当前函数打开，因此当前函数也负责关闭底层文件句柄。
	f, err := os.Open(path)
	if err != nil {
		return nil, fmt.Errorf("打开压缩文件: %w", err)
	}
	defer func() {
		// 只有前面没有更具体的错误时，才把文件关闭错误作为返回值。
		if closeErr := f.Close(); err == nil && closeErr != nil {
			err = fmt.Errorf("关闭压缩文件: %w", closeErr)
		}
	}()

	// flate 只负责解压；它不会替调用方关闭 f。
	zr := flate.NewReader(f)
	defer func() {
		// 解压层先收尾，避免把两层 Close 混成一个错误来源。
		if closeErr := zr.Close(); err == nil && closeErr != nil {
			err = fmt.Errorf("关闭 flate 读取器: %w", closeErr)
		}
	}()

	data, err := io.ReadAll(zr)
	if err != nil {
		return nil, fmt.Errorf("读取解压数据: %w", err)
	}
	return data, nil
}

func main() {
	data, err := readCompressedFile("payload.deflate")
	if err != nil {
		if errors.Is(err, os.ErrNotExist) {
			fmt.Println("输入文件不存在")
			return
		}
		fmt.Println(err)
		return
	}
	fmt.Printf("解压得到 %d 字节\\n", len(data))
}

这里两个 defer 的注册顺序很重要：后注册的 zr.Close 会先执行，随后才执行 f.Close。这与“先收尾解压层、再收尾底层输入”的依赖关系一致。若只需要简单处理且不关心关闭错误，也可以写成两个直接的 defer，但生产代码最好至少记录关闭失败。

为什么读到 EOF 还要显式 Close

读到 io.EOF 表示解压器已经遇到 DEFLATE 流的最后一个块，不等同于“所有拥有者都已经完成资源管理”。flate 的 Close 仍然是返回值要求的一部分，也让代码明确表达：这个解压层不再使用。

当前实现中，如果解压器已经进入正常 EOF 状态，Close 返回 nil；如果此前保存了损坏输入或底层读取错误，Close 可能把该错误返回出来。因此不要把 Close 当成无条件成功的空操作，尤其是流式读取只读了一部分就提前返回时。

循环处理时不要让 defer 堆积

如果每轮都打开一个压缩文件并在大函数里直接 defer，所有关闭动作会拖到外层函数结束才执行。单个文件的处理最好拆成小函数，让每一轮的解压层和底层文件在函数返回时立即释放。

func processOne(path string) error {
	// 把一轮工作包成小函数，使本轮 defer 不会跨越整个批处理循环。
	f, err := os.Open(path)
	if err != nil {
		return fmt.Errorf("打开 %s: %w", path, err)
	}
	defer f.Close() // 底层文件由本轮函数负责收尾。

	zr := flate.NewReader(f)
	defer zr.Close() // 解压层与文件分开关闭，后注册者先执行。

	// 处理函数只消费当前输入，不把 zr 或 f 泄漏给下一轮。
	_, err = io.Copy(io.Discard, zr)
	if err != nil {
		return fmt.Errorf("解压 %s: %w", path, err)
	}
	return nil
}

如果需要把关闭错误汇总到业务错误中，应像前一个示例一样使用命名返回值或显式收尾。这个简化版本重点展示生命周期边界，不建议在需要审计关闭失败的场景直接丢弃 Close 的返回值。

底层是网络流或自定义 Reader 时怎么办

传给 NewReader 的对象只要满足 io.Reader 就能使用。它可能是不会关闭的 bytes.Reader，也可能是应该关闭的网络连接。处理原则不是“永远调用底层 Close”，而是由拥有该对象的代码决定它的生命周期。

• bytes.Reader、内存缓冲区等没有外部资源的 Reader，不需要额外关闭。
• *os.File、HTTP 响应体或连接对象，如果由当前函数创建或持有，就要按各自 API 要求关闭。
• 如果 Reader 由上层传入，当前函数通常不应擅自关闭它，除非接口约定明确写明所有权已经转移。
• 官方文档还提示：输入没有实现 io.ByteReader 时，解压器可能会从输入读取超过当前解压所需的数据；流式协议要据此设计缓冲和所有权。

需要复用时用 Reset，但仍要管理输入

flate.NewReader 返回的读取器还实现了 flate.Resetter。高频处理相同类型的 DEFLATE 数据时，可以复用解压器内部已分配的内存。不过 Reset 只会把解压器切换到新的 io.Reader，不会替新旧输入对象决定何时关闭。

func reuseReader(inputs []io.Reader) error {
	// 先用 nil 创建一个可复用的解压器；实际输入在 Reset 时注入。
	zr := flate.NewReader(nil)
	defer zr.Close() // 复用完成后关闭解压器本身。

	resetter := zr.(flate.Resetter)
	for _, input := range inputs {
		// Reset 丢弃上一轮的缓冲状态，但不拥有 input 的关闭责任。
		if err := resetter.Reset(input, nil); err != nil {
			return fmt.Errorf("重置 flate 读取器: %w", err)
		}
		if _, err := io.Copy(io.Discard, zr); err != nil {
			return fmt.Errorf("读取复用输入: %w", err)
		}
	}
	return nil
}

复用场景最容易混淆的是“解压器只有一个，可以只关一次”和“每个输入都由谁关闭”。这两件事互不冲突：解压器的 Close 管自己；文件、连接或响应体仍按它们各自的所有权规则收尾。

几个容易写错的判断

只关闭文件，不关闭 NewReader 返回值，可以吗？

不建议。文件关闭不能替代解压层的 Close，代码也失去了对解压错误状态的明确收尾。

只关闭 flate Reader，文件会自动关闭吗？

不会。NewReader 接收的是 io.Reader，并不承诺取得底层资源的所有权；文件需要单独关闭。

Close 返回错误时一定要覆盖读取错误吗？

不一定。通常保留更早、更具体的读取或解压错误，再在没有前置错误时记录关闭错误；如果业务要求完整审计，也可以使用错误组合方式统一返回。

把 flate 和 gzip、ZIP 的关闭规则混在一起可以吗？

不可以。本文只讨论裸 DEFLATE 的 compress/flate Reader。gzip、zlib 和 ZIP 还包含各自的容器或条目语义，应按对应包的文档处理。

结论

flate.NewReader 返回的是需要关闭的解压层，而不是底层输入的代理。实际代码可以记成三句话：读取器创建后尽快安排 Close；底层文件或连接由拥有者单独关闭；循环处理把每一轮生命周期收进小函数。这样既不会把文件句柄误认为解压器资源，也能在异常和复用场景中保留清晰的责任边界。