Go compress/gzip 怎样复用 gzip Writer 并正确重置

批量生成压缩文件时，反复调用 gzip.NewWriter 会不断创建新的压缩器；但如果任务是串行处理多个独立数据块，可以复用同一个 gzip.Writer。关键顺序只有一句话：先 Close 完当前 gzip 流，再 Reset 到新的 io.Writer，最后重新设置这一条流的 Header。

先分清 Close、Flush 和 Reset 的边界

gzip.Writer 是一个带缓冲的 io.WriteCloser。调用 Write 后，压缩字节不一定已经完整写到底层目标；Flush 只把当前挂起的压缩数据推下去，适合需要持续发送数据的协议；Close 除了刷新，还会写入这一条 GZIP 流的尾部信息。

Reset(w) 的语义是“把这个 Writer 恢复成刚由 NewWriter 或 NewWriterLevel 创建出来的状态，但改写到新的 w”。因此它适合回收压缩器内部状态，却不负责替上一条流补尾部。若跳过 Close 直接 Reset，上一条输出可能没有完整结束。

用一个 Writer 依次压缩两条独立数据

下面把两条记录分别写入两个 bytes.Buffer，模拟批处理中的两个独立输出目标。每一轮都先写入内容，再关闭当前 gzip 流，之后才能将同一个 Writer 重置到下一块缓冲区。

package main

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

func compressBatch(items []string) ([][]byte, error) {
    var outputs [][]byte
    var sink bytes.Buffer
    zw := gzip.NewWriter(&sink)

    for i, item := range items {
        sink.Reset() // 每轮使用独立的底层缓冲区，避免把旧字节当成新结果
        zw.Reset(&sink) // 先让同一个压缩器指向本轮输出目标
        zw.Name = fmt.Sprintf("record-%d.txt", i+1) // Header 必须在本轮首次 Write 前设置

        if _, err := zw.Write([]byte(item)); err != nil {
            return nil, fmt.Errorf("写入第 %d 条记录失败: %w", i+1, err)
        }
        if err := zw.Close(); err != nil {
            return nil, fmt.Errorf("关闭第 %d 条 gzip 流失败: %w", i+1, err)
        }

        // 复制结果，避免下一轮 Reset 后继续复用同一块缓冲区的内容。
        outputs = append(outputs, append([]byte(nil), sink.Bytes()...))
    }
    return outputs, nil
}

func main() {
    outputs, err := compressBatch([]string{"第一条数据", "第二条数据"})
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(len(outputs)) // 这里只展示批次条数，不把压缩字节当作固定文本
}

这里有三个容易漏掉的细节。第一，Close 后再调用 Reset，保证当前成员已经写完 footer。第二，Reset 后重新设置 Name 等 Header 字段；Header 会在本轮第一次 Write、Flush 或 Close 时写出。第三，示例把缓冲区内容复制到新的字节切片中，否则下一轮复用 sink 后，调用方拿到的结果也会跟着变化。

Reset 后为什么要重新设置 Header

如果每个压缩成员都需要不同的文件名、注释或修改时间，就不能只在 NewWriter 后设置一次。Reset 会让 Writer 回到可重新配置的初始状态；应该在每次 Reset 后、第一次写入前赋值。

func writeOne(zw *gzip.Writer, dst *bytes.Buffer, name string, data []byte) error {
    dst.Reset() // 清空本轮底层缓冲区，避免混入上一条结果
    zw.Reset(dst) // 切换到新的输出目标
    zw.Name = name // 当前 gzip 成员使用自己的文件名
    zw.Comment = "batch member" // 注释也是当前成员的 Header 元数据

    if _, err := zw.Write(data); err != nil {
        return err
    }
    return zw.Close() // 关闭当前成员，写出 footer 后才允许进入下一轮
}

不要依赖压缩后的字节逐次完全相同，也不要把 Header 当作底层文件句柄的生命周期。Go 文档明确区分了 gzip Writer 与底层 io.Writer：前者关闭时会完成 gzip 数据，后者是否关闭要由调用方决定。

哪些场景适合复用，哪些场景不要复用

当输入是一批顺序处理的记录，且每条记录都有自己的输出缓冲区或文件句柄时，复用同一个 Writer 能减少重复初始化，代码也容易控制资源边界。复用的前提是上一条流已经 Close，并且调用方已经处理或复制了上一条结果。

如果多个 goroutine 同时压缩不同数据，应该给每个任务单独创建 Writer，或通过串行所有权把 Writer 限制在一个 goroutine 内。不要把“减少分配”变成共享可变状态；gzip.Writer 的复用接口解决的是串行生命周期，不是并发安全。

• 输出是文件时：先 Close gzip Writer，再按文件对象的规则决定是否关闭文件。
• 输出是长连接时：需要边写边让对端读取，可以考虑 Flush，但一条独立流结束仍要 Close。
• 结果要长期保存时：不要直接返回会被下一轮 Reset 覆盖的底层缓冲区，先复制或转移所有权。
• 需要多个独立 gzip 成员时：每个成员都要有自己的 Header 设置和 Close 边界，不要把上一条的元数据当成默认值。

常见问题

Reset 前一定要 Close 吗？

如果当前 Writer 已经写过数据，应该先 Close 完当前 gzip 流再 Reset。Reset 负责重置状态和切换目标，不负责替上一条流写 footer。

Close 之后还能继续 Write 吗？

不要把 Close 后的 Writer 当作同一条流继续写。要开始新的独立输出，应先 Reset 到新的目标，然后重新设置 Header，再写入数据。

复用 Writer 就一定更快吗？

不一定。它减少的是重复创建和初始化的机会，实际收益取决于数据量、压缩级别和底层 I/O。先明确串行资源边界，再用真实批次衡量，别为了复用牺牲代码可读性。

最终可以把复用规则记成四步：Write → Close → Reset → 重新设置 Header。只要每条 gzip 流都有清晰的结束点，并且不跨 goroutine 共享同一个 Writer，复用就能保持简单可控。