gzip Reader 复用后旧缓冲数据残留的处理

复用 gzip.Reader 后看到“旧数据”，先不要把问题归咎于 Reset。Go 的 Reset 会丢弃 Reader 自身状态，并让它从新的 io.Reader 读取；更常见的残留来源是调用方没有清空输出缓冲、输入源仍停留在旧位置，或在返回 io.EOF 前就把已读字节当成完整结果。

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

先定位旧数据到底来自哪里

一个 gzip.Reader 同时维护当前 gzip 头信息、解压进度和校验状态。它读取的是传入的 io.Reader，输出则写入调用方提供的切片或缓冲区。于是“第二份数据前面多出第一份内容”至少有三种可能：Reader 没有 Reset、输入源没有换成第二份，或者输出缓冲只是复用了容量却没有清空长度。

可以把边界画成一条线：Reader 的状态由 Reset 管；输入源的当前位置由外部 Reader 管；最终拼接、覆盖还是清空由业务缓冲管。不要用一个对象的重置方法替代另一个对象的清理动作。

用 Reset 复用 Reader，而不是继续消费旧输入

第一次创建 Reader 后，后续每份 gzip 数据都应该调用 Reset 绑定新的输入。如果 Reset 返回错误，说明新输入的 gzip 头无法建立，不能继续使用本轮结果。

package main

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

func readOne(zr *gzip.Reader, compressed []byte) (string, error) {
    // 每次都把 Reader 绑定到新的 gzip 字节流，旧的解压状态不会跨输入保留。
    if err := zr.Reset(bytes.NewReader(compressed)); err != nil {
        return "", fmt.Errorf("重置 gzip Reader: %w", err)
    }

    var out bytes.Buffer
    // io.Copy 会持续读取直到 EOF；校验错误会通过返回值暴露出来。
    if _, err := io.Copy(&out, zr); err != nil {
        return "", fmt.Errorf("读取 gzip 数据: %w", err)
    }
    return out.String(), nil
}

func readMany(first []byte, second []byte) error {
    // 先创建一次 Reader，后续通过 Reset 复用它，避免每份输入都重新分配对象。
    zr, err := gzip.NewReader(bytes.NewReader(first))
    if err != nil {
        return fmt.Errorf("创建 gzip Reader: %w", err)
    }
    defer zr.Close()

    for _, compressed := range [][]byte{first, second} {
        text, err := readOne(zr, compressed)
        if err != nil {
            return err
        }
        fmt.Println(text)
    }
    return nil
}

示例中 readOne 每次都创建新的输出缓冲，所以不会把上一次的字符串拼到下一次。真正的复用点只有 gzip.Reader；如果业务还要复用 bytes.Buffer，应在下一轮开始前调用 Reset(nil) 或明确设置新的长度，而不是只复用底层容量。

读到 EOF 后，才确认完整数据和校验结果

gzip 尾部包含未压缩数据的长度和校验值。官方文档明确说明，Reader 返回的字节在收到 io.EOF 之前都应视为暂定数据；如果长度或校验不匹配，Reader 会在读到未压缩数据末尾时返回 ErrChecksum。因此，读取若在中途因为业务截断、连接中断或其他错误退出，不能把已经写入输出缓冲的部分内容标为完整成功。

func readAll(zr *gzip.Reader) ([]byte, error) {
    var out bytes.Buffer
    buf := make([]byte, 32*1024)

    for {
        n, err := zr.Read(buf)
        if n > 0 {
            // 先保存本次得到的字节，但最终是否完整仍由 err 的结论决定。
            if _, writeErr := out.Write(buf[:n]); writeErr != nil {
                return nil, fmt.Errorf("写入输出缓冲: %w", writeErr)
            }
        }
        if err == io.EOF {
            // EOF 表示已经走到 gzip 流末尾，且校验流程完成。
            return out.Bytes(), nil
        }
        if err != nil {
            // ErrChecksum、底层读取错误都不能被部分输出掩盖。
            return nil, fmt.Errorf("gzip 流未完整结束: %w", err)
        }
    }
}

如果只关心把数据传给另一个 Writer，可以使用 io.Copy，它会把读取错误返回给调用方。无论采用哪种写法，都不要只检查“输出缓冲非空”这一条件。

清理应用层缓冲，处理多流输入边界

下面这种代码会制造“旧数据残留”的错觉：

var out bytes.Buffer
for _, compressed := range inputs {
    // Reader 每轮重置了，但 out 仍然保留上一轮的内容。
    if err := zr.Reset(bytes.NewReader(compressed)); err != nil {
        return err
    }
    if _, err := io.Copy(&out, zr); err != nil {
        return err
    }
    fmt.Println(out.String()) // 这里打印的是累计内容，不是当前文件内容。
}

如果每轮需要独立结果，应把 bytes.Buffer 放进循环，或者在下一轮前调用 out.Reset()。如果设计目标就是累计所有明文，则应把它明确命名为聚合缓冲，并在输出逻辑中接受“前缀会保留”的结果。

还要注意 gzip 多流。Reader 默认允许把多个连续 gzip 数据流看成一个解压后的连续结果；如果文件格式要求每个流单独处理，应调用 Multistream(false)，读完当前流后再 Reset 到下一段输入。此时底层 Reader 需要能准确停在当前 gzip 流之后。

复用场景的判断清单

常见问题

调用 Reset 后还需要创建新的 gzip.Reader 吗？

不需要。只要对象没有并发使用，Reset 就是官方提供的复用方式；但必须检查它返回的错误，并保证上一轮读取已结束或已按业务放弃。

Close 会不会清空底层 bytes.Buffer？

不会。gzip.Reader.Close 只关闭 Reader 自身，不关闭底层 Reader，也不会替调用方清空输出缓冲。完整校验仍依赖读到 io.EOF。

只要拿到了所有 Read 返回的字节，就可以忽略 EOF 吗？

不可以。EOF 是完整结束的信号，校验失败也可能在流尾才暴露。没有拿到 EOF，已返回的字节不能单独证明数据完整有效。

gzip.Reader 可以在多个 goroutine 之间共享吗？

不应直接共享。复用 Reader 是串行生命周期管理，不等于并发安全；并发读取应为每个独立任务创建自己的 Reader 或建立明确的同步边界。