Go gzip.Writer 怎么用 Reset 复用压缩器

我第一次把多份日志分别压成 gzip 文件时，直觉是每轮都调用 gzip.NewWriter。代码当然能跑，但批处理量一大，反复创建压缩器就成了没有必要的开销。Go 的正确复用方式是：一个 gzip.Writer 处理一份数据，写完后先 Close，再调用 Reset 切换到新的 io.Writer。Close 负责补齐当前 GZIP 流的 footer，不能用 Reset 直接代替。

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

记住一条顺序就够了：Write → Close → Reset → Write。每个输出目标都独立保存，底层的 bytes.Buffer 或文件由调用方负责管理。

Reset 复用的关键是先 Close 再切换输出

gzip.Writer 实现了 io.WriteCloser。调用 Write 时，数据可能仍停留在压缩器内部；只有 Close 才会把未写出的内容推到底层 writer，并写入 GZIP footer。此时再 Reset，压缩器才适合服务下一份独立输出。

下面的例子把两份字符串写进不同的 buffer。这里刻意保留每轮的 Close 错误检查，因为底层 writer 失败时，错误可能在收尾阶段才暴露。

package main

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

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

    for _, item := range items {
        buf.Reset()
        zw.Reset(&buf) // 切换到本轮输出前，先清空可复用的 buffer

        if _, err := io.WriteString(zw, item); err != nil {
            return nil, fmt.Errorf("写入 gzip 数据失败: %w", err)
        }
        if err := zw.Close(); err != nil { // Close 会写完缓冲数据和 GZIP footer
            return nil, fmt.Errorf("关闭 gzip 流失败: %w", err)
        }

        // 复制一份结果，避免下一轮复用 buf 后覆盖本轮数据。
        out = append(out, append([]byte(nil), buf.Bytes()...))
    }
    return out, nil
}

这个写法有一个容易忽略的细节：Reset 重置的是 gzip.Writer，而 bytes.Buffer.Reset 清的是缓冲区内容。结果需要长期保存时，必须复制 buf.Bytes()；否则下一轮复用 buffer 后，之前保存的切片可能看到同一块底层存储。

把压缩器放进批处理循环时要固定三件事

实际项目里，复用通常发生在导出、归档或按租户分片的循环中。我会把下面三点写成不容易被后续修改破坏的约定。

1. 输出目标要明确。 Reset 接收新的 io.Writer，它不会替调用方关闭旧文件，也不会自动创建新文件。
2. 结束当前流再切换。 如果在 Close 前直接 Reset，当前流的尾部可能没有写出，读取端就可能遇到截断或校验错误。
3. 结果不要引用可变 buffer。 文件可以直接写完交给文件句柄；内存 buffer 则要在进入下一轮前复制或消费。

如果输出是文件，gzip.Writer.Close 不会替你关闭底层文件，应该在外层明确决定文件句柄何时关闭。这样压缩器的生命周期和文件生命周期不会被混在一起。

Flush、Close 和 Reset 该怎么选

三个方法都和“把数据送出去”有关，但语义并不相同。尤其是网络协议里，Flush 可能很有用；对于要独立保存的 gzip 文件，结尾仍然要靠 Close。

压缩 HTTP 流或自定义长连接协议时，可以在合适的消息边界调用 Flush，让远端尽快拿到可解码的数据；批量文件则按“写入、Close、保存结果、Reset”的顺序处理。不要为了“保险”在每次 Write 后都 Flush，这会牺牲压缩效率并增加底层写入次数。

复用中的元数据和错误边界

Writer 的 Name、Comment、ModTime 等 header 字段，应在本轮第一次 Write、Flush 或 Close 之前设置。写出 header 后再改字段，不会回头修改已经写出的字节。

验证复用是否正确时，不要只比较压缩后的字节长度。官方文档明确提示，压缩器输出的精确字节不属于 Go 1 兼容保证；更可靠的检查是分别用 gzip.NewReader 解压每个结果，再比较解压后的原文。读取端要持续读到 io.EOF，这样才能让 checksum 校验完成。

func unpack(data []byte) (string, error) {
    zr, err := gzip.NewReader(bytes.NewReader(data))
    if err != nil {
        return "", err
    }
    defer zr.Close() // Reader.Close 不关闭底层 bytes.Reader

    raw, err := io.ReadAll(zr) // 读到 EOF，才能完整验证 GZIP checksum
    if err != nil {
        return "", err
    }
    return string(raw), nil
}

常见问题

Reset 之后还需要重新设置压缩级别吗？

普通 Reset 会保留原先创建时采用的压缩器配置语义，但会丢弃本轮 Writer 状态。若需要改变压缩级别，应重新创建 gzip.Writer，而不是把 Reset 当成配置修改 API。

Close 后还能继续 Write 吗？

不要把已 Close 的 Writer 当作仍可追加的流。先完成当前结果，再 Reset 到新的目标；每份独立内容都应有自己的结束边界。

为什么输出结果不能直接保存 buf.Bytes？

因为下一轮可能复用同一个 bytes.Buffer 的底层数组。需要跨轮保存时复制字节，或者立即把它写入最终文件、网络响应等不会被下一轮清空的目标。