Go flate Reset 后为什么还会读到上一段状态

我在把多段 DEFLATE 数据放进复用池时遇到过一个很容易误判的现象：第二段调用 Reset 后，输出末尾像是上一段内容。先给结论：flate.Reset 会丢弃解压器自己的位缓冲、霍夫曼状态和历史窗口，并把它切换到新的 io.Reader；它不会替你清空 bytes.Buffer、移动输入 reader 的游标，也不会擦掉已经写入输出缓冲的字节。

Reset 到底重置了哪些状态

flate.NewReader 返回的读对象同时实现 flate.Resetter。调用 Reset(r, dict) 后，解码器会按照“刚用这个 reader 初始化”的状态工作，并重新设置可选字典。它复用了已经分配的内存，所以适合高频解压，但“复用内存”不等于“复用上一段数据”。

真正容易被忽略的是调用边界：r 只是新的数据来源，Reset 不知道你是否还在复用一个可写的 bytes.Buffer，也不知道你把上一次输出追加到了哪里。下面这张结构图把解压器内部边界和调用方缓冲边界分开，排查时先看外层。

一个不会混淆输入和输出的复用写法

复用时我会把“压缩数据的生成”和“解压数据的收集”分成两个明确的缓冲区。每轮开始先清空输出，压缩器写完并关闭当前段，再让解压器 Reset 到这段的输入。示例中的注释只解释关键边界，没有把运行结果冒充截图。

package main

import (
    "bytes"
    "compress/flate"
    "fmt"
    "io"
    "log"
)

func main() {
    messages := []string{"第一段数据", "第二段数据"}
    var compressed bytes.Buffer
    var output bytes.Buffer

    // 复用一个压缩器；每次 Reset 只更换压缩输出目标。
    zw, err := flate.NewWriter(&compressed, flate.DefaultCompression)
    if err != nil {
        log.Fatal(err)
    }
    // 解压器先绑定一个空 reader，后续通过 Resetter.Reset 换段。
    zr := flate.NewReader(bytes.NewReader(nil))
    defer zr.Close()

    for _, message := range messages {
        compressed.Reset()
        output.Reset()

        // Close 会写出当前 DEFLATE 段的结束信息，不能只调用 Write。
        zw.Reset(&compressed)
        if _, err := zw.Write([]byte(message)); err != nil {
            log.Fatal(err)
        }
        if err := zw.Close(); err != nil {
            log.Fatal(err)
        }

        // Reset 不会清空 output；本轮已经显式 Reset，避免旧结果继续存在。
        if err := zr.(flate.Resetter).Reset(bytes.NewReader(compressed.Bytes()), nil); err != nil {
            log.Fatal(err)
        }
        if _, err := io.Copy(&output, zr); err != nil {
            log.Fatal(err)
        }
        // 读到 EOF 后，output 只包含当前段；此处打印用于观察本轮结果。
        fmt.Printf("%s\n", output.String())
    }
}

这里有一个细节：示例把 compressed.Bytes() 交给 bytes.NewReader，所以每轮的输入游标从零开始。若直接复用同一个 *bytes.Reader，就必须在 Reset 前调用它的 Reset；若输入来自网络，则不能把“换了解压器”误认为“换了协议帧”。帧边界仍然要由上层协议准确切出。

读到上一段内容时，按四个边界定位

尤其不要在每次 Reset 后只读一次 Read 就认为当前段完成。一次 Read 可能只返回部分数据，应该持续读取直到 io.EOF，或者交给 io.Copy。官方实现会在最终 DEFLATE block 后返回 EOF；底层 reader 在不实现 io.ByteReader 时还可能被内部缓冲多读一些，因此协议层更应该先完成明确的帧切分。

上线前固定这份复用清单

1. 一段压缩数据对应一个明确的输入 reader，不把上一段未消费的字节直接拼进下一段。
2. 输出目标在段边界清空，或者为每段创建新的 bytes.Buffer。
3. 写端总是检查 Close，读端持续到 io.EOF，其他错误直接返回。
4. 预置字典参与协议约定；Reset 时不要为了“清状态”随意把非 nil 字典改成 nil。
5. 解压器不是并发安全对象；池化时每个并发任务独占实例，归还前确认本段已读完。

我的判断是：如果 Reset 后看到上一段内容，先不要给 flate 加锁或重建对象。先把输入、解码器和输出画成三个变量，逐个打印本轮长度与错误，通常几分钟就能找到是外部缓冲追加还是输入边界错位。只有确认对象被并发使用，才需要进一步检查池化生命周期。

常见问题

调用 flate.Reset 后还需要重新创建解压器吗？

不需要。它的目的就是复用已经分配的读对象；只有不需要复用、生命周期很短或并发隔离更重要时，重新创建才更简单。

Reset 会自动清空 bytes.Buffer 吗？

不会。bytes.Buffer 属于调用方对象，必须由调用方调用 Reset，或为本段使用新的 buffer。

为什么不能只看一次 Read 的返回值？

Reader 允许部分读取。要判断一段 DEFLATE 数据完整结束，应持续读到 io.EOF；遇到 io.ErrUnexpectedEOF 或其他错误则说明输入不完整或底层读取失败。