Go compress/gzip Reader 怎样复用并正确关闭

Go compress/gzip 的 Reader 可以用 Reset 切换到下一份输入，顺序复用解压器；用完仍要 Close，而且底层文件或连接必须由它自己的所有者关闭。还要区分“清理成功”和“内容读取完整”：提前停止后调用 Close，并不等于已经检查了 gzip 尾部校验。

官方文档地址：https://pkg.go.dev/compress/gzip

我会先检查为什么关闭了还没有完整结果

设想一个顺序处理多个 gzip 导入文件的程序：它只读了前几行就说成功，随后调用 Reader.Close，却又出现后半段损坏未被发现、文件句柄迟迟不释放的疑问。我会先把这两件事分开追查，而不是把所有问题都归因于 Reset。以下是原创的假设故障分析，不是真实事故时间线或实测报告。

按代码顺序看，创建 Reader 只能说明头部初始化通过；读出一段内容说明暂时拿到了一些解压数据；调用 Close 是清理动作。把这三个阶段都理解成“整个文件已经有效”，才是这个场景的根本误判。

另一个触发条件是把文件的 defer Close 写在长批次循环所在的函数里。每轮都会登记 defer，但不会在该轮结束时执行；如果输入很多，多个底层文件可能同时存活。对我来说，修复重点是缩小每份输入的生命周期，而不是把 defer 全部去掉。

Reset 复用的是解压器，不是旧文件

Reset 会丢弃当前 Reader 的读取状态，改从传入的新 reader 解压；它不是“把旧文件自动关闭后再打开新文件”的工具。Reader.Close 只关闭解压层，不负责底层 reader，因此每次打开文件的代码必须保留自己的 f.Close。

我会把复用对象放在串行处理器 counter 中，把 os.File 放在单次调用里。前者可以跨文件保留，后者不能跟着批次一直拖到最后。复用也不意味着可以并发操作同一个 Reader：前一份输入没有结束时调用 Reset，会破坏它原有的读取状态。

把每个文件的生命周期收进一个小函数

下面的原创完整示例只统计解压字节，不输出实际内容。首份文件创建 Reader，后续文件调用 Reset；每次 countFile 返回前完成解压层和文件层的关闭。使用 errors.Join 合并清理错误，因此示例面向 Go 1.20 及以上。

package main

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

// 这是单个输入允许的解压字节数，不是压缩文件大小或内存上限。
const maxPlain int64 = 8  maxPlain {
        return 0, errors.New("uncompressed input exceeds limit")
    }
    if readErr != io.EOF {
        // 校验和、截断等错误不能由后面的Close覆盖。
        return 0, fmt.Errorf("read gzip: %w", readErr)
    }
    return n, nil // 此处才允许把读取字节数作为完整结果返回。
}

func run(paths []string) error {
    var c counter
    for i, path := range paths {
        size, err := c.countFile(path)
        if err != nil {
            // 不使用失败调用的size，也不声称后续文件已处理。
            return fmt.Errorf("input %d: %w", i+1, err)
        }
        fmt.Printf("input=%d uncompressed=%d\n", i+1, size)
    }
    return nil
}

func main() {
    if len(os.Args) 

这段代码尚未执行，8 MiB 是示例的输入政策，不是性能测试结果。io.Discard 让示例不保留整份明文，重点留给复用与清理。如果改成写入数据库、响应或最终文件，必须额外安排暂存、事务或提交策略，不能把已输出的部分内容当成可自动回滚。

两个 defer 按后登记先执行的规则先关闭解压层、再关闭底层文件。命名返回值 err 让清理错误与读取错误一并返回；调用方必须先检查 err，再使用 size，即使 size 看起来已经是一个正常数字。

我没有让初始化失败的 Reader 继续 Read，也没有在失败后继续处理下一文件。示例采取停止批次的简单策略，避免给“损坏对象何时重新入池”引入额外规则。需要容错继续时，应明确丢弃失败实例，重新创建，而不是忽略 Reset 错误。

提前停止、拼接成员和元数据有哪些陷阱

最值得注意的是 EOF 的来源。这个示例用 CopyN 尝试读取上限加一个字节：读到多出的字节就拒绝；未超限且得到来自 gzip 的 EOF，才记录完整读取。若把 gzip.Reader 包进 LimitReader，外层限额到达也会给出 EOF，不能据此宣称原 gzip 内容和尾部都已经读完。

超过上限时，我选择直接关闭并返回拒绝，不为了“完成校验”继续把剩余内容排空。解压字节限额不等于压缩输入大小、CPU 时间、成员数量或进程内存上限；处理不可信输入还需要独立约束输入体积、耗时和并发。本例针对受控的本地文件，不是完整的解压安全网关。

gzip 默认接受拼接成员，示例显式启用 Multistream(true)，把同一输入内所有成员的明文合计在一个上限内。如果只想逐成员处理，需要在每次 Reset 后重新调用 Multistream(false)，并保留一个支持 io.ByteReader 的底层读取器，才能可靠保留下一成员起点。这与“下一个独立文件”的复用方式不同，本文不把两种模式混写。

Header 也属于当前读取状态。Reader 的元数据不是整个批次的历史记录，默认拼接读取只记录首个头。若要跨 Reset 保存 Extra 等切片字段，应复制所需数据；不要长期拿当前 Header 当成所有输入的不可变快照。Name 等文件内元数据也不应该直接决定输出路径。

我会为复用保留这些观察点

读者可把代码保存为 main.go，准备自己拥有的两份完整 gzip 文件，再尝试运行下面的命令。本文未运行该命令，没有附上虚构字节数。

# first.gz和second.gz为读者自行准备的本地测试输入。
go run main.go first.gz second.gz

这些是接入前的观察计划，不是已经通过的测试清单。我更愿意先确认完整性与所有权，再考虑对象池；没有内存分配或性能测量时，不应宣称 Reset 带来多少百分比提升。

只调用 Reset 不 Close 也能换输入吗？

Reset 能切换状态，但不能替代底层资源清理。本文固定每次成功初始化后都安排 Reader.Close，并单独关闭当前文件，避免让“可以复用”被误读成“不必清理”。

Close 返回 nil 能证明压缩包没坏吗？

不能。必须检查读取过程中是否报错，以及是否真正读到了 gzip 的 EOF；清理结果不是内容真实性或安全性的证明。

需要立即引入 sync.Pool 吗？

不必。顺序任务先保留一个 Reader 就能说明复用；只有量化过分配压力，再为池的借出、独占、归还和失败丢弃制定明确规则。

我的结论是把“复用对象”“逐输入关闭”“完整读取”写成三份独立契约。这样即使将来把文件输入换成连接，也知道哪一层负责结束读取、哪一层负责释放资源，以及什么时候才能对外说处理完成。

参考：gzip.Reader 文档、Reset 与读取实现、io.CopyN 文档。