Go gzip.Reader.Reset 怎样复用解压读取器

批量解压多个独立的 gzip 数据时，可以先创建一个 gzip.Reader，每处理完一个输入，再调用 Reset 绑定下一个输入。它会丢弃 Reader 当前的读取状态，同时保留对象本身，从而避免每轮都重新分配 Reader。

关键顺序只有三点：Reset 的错误先处理，Read 返回 EOF 才算当前输入读完，最后再 Close。Reset 失败时不要继续调用 io.Copy，否则读到的不是一个有效的 gzip 流。

先理解 Reset 到底重置了什么

官方文档把 Reader.Reset(r) 定义为：丢弃 Reader 的状态，让它等价于刚由 NewReader 创建出来的对象，但新的数据来源变成参数 r。因此它不是“把当前位置移回开头”，而是把同一个解压读取器切换到另一份输入。

Reset 还会重新读取 gzip 头部；头部损坏、输入为空或输入不是 gzip 数据时，它可能直接返回错误。只有返回 nil 后，才进入读取正文的阶段。

批量输入的正确写法

第一次输入使用 gzip.NewReader，后续输入调用同一个 Reader 的 Reset。下面的函数接收多份已经压缩好的字节数据，逐份返回解压结果：

package main

import (
    "bytes"
    "compress/gzip"
    "fmt"
    "io"
)

func decodeMany(inputs [][]byte) ([][]byte, error) {
    if len(inputs) == 0 {
        return nil, nil
    }

    // 第一次输入需要创建 Reader，后续轮次复用同一个对象。
    zr, err := gzip.NewReader(bytes.NewReader(inputs[0]))
    if err != nil {
        return nil, fmt.Errorf("创建 gzip.Reader: %w", err)
    }
    defer zr.Close()

    outputs := make([][]byte, 0, len(inputs))
    for index, input := range inputs {
        if index > 0 {
            // Reset 会重新读取 gzip 头；失败时当前输入不能继续解压。
            if err := zr.Reset(bytes.NewReader(input)); err != nil {
                return nil, fmt.Errorf("第 %d 个输入无效: %w", index+1, err)
            }
        }

        var out bytes.Buffer
        // io.Copy 只有在读到 EOF 后才表示这一份 gzip 数据完整消费。
        if _, err := io.Copy(&out, zr); err != nil {
            return nil, fmt.Errorf("第 %d 个输入读取失败: %w", index+1, err)
        }
        outputs = append(outputs, append([]byte(nil), out.Bytes()...))
    }
    return outputs, nil
}

这里的 defer zr.Close() 只负责函数结束时关闭最后一次绑定的 Reader。每轮并不需要创建和关闭一个新 Reader；Reset 已经负责切换输入。

Reset 错误和 Read 错误要分开判断

Reset 主要暴露新输入的 gzip 头部问题，Read 阶段则可能暴露压缩数据截断或校验和不匹配。gzip Reader 的文档特别提醒：在收到标记完整结束的 io.EOF 之前，Read 已经返回的字节只能视为暂定结果。

所以不要只检查“已经拿到了一些字节”。如果 io.Copy 返回错误，应丢弃这份输出；如果使用手写 Read 循环，也要把 EOF 作为完整性判断的一部分。

Multistream 与 Reset 不是一回事

gzip 文件可以由多个 gzip 成员拼接而成。默认情况下，Reader 的 multistream 行为是开启的，会继续读取后续成员。这个问题与“批量处理多份独立输入”不同：

• 同一份拼接 gzip 数据：通常由一个 Reader 在一次读取中处理，关注 Multistream。
• 多份彼此独立的输入：每份处理完成后，调用 Reset 绑定下一份。

如果你的格式要求在第一个 gzip 成员结束后保留底层 Reader 的位置，可以先调用 Multistream(false)。这时底层输入需要实现 io.ByteReader，并且开始下一成员时要重新 Reset，再按需要设置 multistream 行为。

怎样比较复用是否真的值得

复用减少的是 Reader 对象及其内部解压状态的重复初始化，不会让 gzip 解码本身消失。输入很少时，代码简单通常比微小的分配差异更重要；当一个长生命周期 worker 需要连续处理大量小 gzip 输入时，再用基准确认收益。

func BenchmarkDecodeWithReset(b *testing.B) {
    inputs := prepareCompressedInputs() // 注释：准备固定输入，避免把生成压缩数据算进基准。
    b.ReportAllocs()
    for b.Loop() {
        if _, err := decodeMany(inputs); err != nil {
            b.Fatal(err) // 注释：基准遇到解压错误必须立即失败，不能吞掉结果。
        }
    }
}

对比时保持输入数量、压缩内容、输出消费方式一致，只替换“每次 NewReader”与“Reset 复用”的实现。关注每次操作的分配次数和耗时，不要把一次偶然的本地结果写成所有数据规模都成立的结论。

复用时最容易踩的几个边界

一句话结论

gzip.Reader.Reset 适合把同一个 Reader 重新绑定到下一份 gzip 输入；它不是回退游标，也不是错误恢复按钮。正确用法是先检查 Reset，再完整读取到 EOF，最后关闭 Reader，并用基准确认批量复用确实值得。

相关问题

Reset 后需要重新调用 Multistream 吗？

Reset 会把 Reader 恢复到类似 NewReader 的初始状态，默认 multistream 为开启。若业务需要关闭拼接成员行为，应在每次 Reset 后明确设置 Multistream(false)。

Reset 能不能把坏输入变成可读输入？

不能。Reset 只绑定新输入并读取头部；如果输入无效，它会返回错误。修复输入后可以再次 Reset 到另一份有效 Reader，但不要继续使用失败轮次的输出。

为什么已经读到一些数据仍然不能认为成功？

gzip 的长度和校验和在流尾部确认。只有读到 io.EOF 才能把当前输出视为完整；中途错误意味着已返回的数据可能不完整。