Go compress/zlib.Reset 怎样复用压缩器缓冲区

批量压缩日志、消息或缓存快照时，如果每个数据块都重新调用 zlib.NewWriter，会反复建立压缩器和校验状态。更合适的做法是创建一次 *zlib.Writer，每个数据块完成后调用 Close，再用 Reset 把它切换到下一个输出缓冲区。

官方地址：https://pkg.go.dev/compress/zlib

结论：Reset 复用的是压缩器对象和内部状态容器，不是把上一份压缩结果自动拼到下一份里。每一份独立 zlib 数据都要先 Close，并且要保存自己的输出缓冲区。

先分清 Reset、Flush 和 Close

zlib.Writer.Reset(w) 会把 Writer 的目标写入器改成 w，清除错误和头部状态，并重置底层 flate 压缩器；压缩级别与字典配置会保留。它适合“同一套压缩配置，连续处理多个独立输出”的场景。

Flush 只是把当前压缩流中暂存的数据推给底层写入器，流还没有结束；Close 才会写完尚未输出的数据和 zlib 校验尾部。下一个数据块不能仅靠 Flush 分隔，否则前一个流仍处于打开状态。

最小复用写法：每个结果留一个 Buffer

下面的配方把每个输入块压缩成一份独立字节切片。关键顺序是先创建第一份输出缓冲区，再写入并关闭；保存结果后，创建下一份缓冲区并调用 Reset。

package main

import (
	"bytes"
	"compress/zlib"
	"fmt"
)

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

	results := make([][]byte, 0, len(chunks))
	var out bytes.Buffer
	w := zlib.NewWriter(&out)

	for index, chunk := range chunks {
		// 每轮先清空当前输出容器，避免把上一个结果带入本轮。
		out.Reset()
		if index > 0 {
			// Reset 复用 Writer，但让它指向本轮新的输出缓冲区。
			w.Reset(&out)
		}
		if _, err := w.Write(chunk); err != nil {
			return nil, fmt.Errorf("写入第 %d 个数据块失败: %w", index, err)
		}
		// Close 会写出压缩尾部；只 Flush 不能得到完整独立流。
		if err := w.Close(); err != nil {
			return nil, fmt.Errorf("关闭第 %d 个压缩流失败: %w", index, err)
		}
		// 复制结果，避免下一轮 Reset/写入改变已保存的数据。
		results = append(results, append([]byte(nil), out.Bytes()...))
	}
	return results, nil
}

这个例子把“输出容器”和“压缩器对象”分开看：out 负责承接当前结果，w 负责压缩状态。结果追加到 results 后要复制一份，因为复用同一个缓冲区时，后续写入会覆盖它的底层数组。

为什么 Reset 后仍然要重新处理输出缓冲区

Reset 不会替你管理业务层的结果集合，也不会替你复制字节。若把同一个 bytes.Buffer 直接放进结果切片，下一轮 out.Reset() 会让先前结果失去独立性；若每轮都新建 Buffer，则可以省去复制，但要把每个 Buffer 的所有权交给调用方。

更稳妥的边界有两种：

• 结果较小、需要返回连续字节：复用一个 Buffer，并在追加时复制 out.Bytes()。
• 结果较大、可以转移所有权：每轮创建新的 bytes.Buffer，Reset 直接指向它，处理后把 Buffer 或其字节切片交给调用方。

封装时要守住这几个边界

第一，*zlib.Writer 不能被多个 goroutine 同时写入或 Reset；如果并发压缩，应当为每个任务准备独立 Writer，或通过池把对象借给单个任务。

第二，Reset 保留创建时的压缩级别和字典。如果不同数据块需要不同级别或不同字典，不能只 Reset 后继续写，应重新创建对应配置的 Writer。

第三，Close 只关闭压缩流，不会关闭底层 io.Writer。文件、网络连接等资源仍由外层负责；如果 Close 返回错误，当前结果不要加入成功集合。

第四，压缩字节的具体排列不适合作为跨版本的精确断言。测试应优先解压后比较原始内容，或者检查能否被合法的 zlib Reader 完整读取。

一张速查表：什么时候复用，什么时候重建

相关问题

Reset 前必须调用 Close 吗？

对于要保留为完整独立压缩流的结果，必须先 Close。未完成收尾就 Reset，上一流的尾部和校验信息可能没有写入，结果不可作为完整 zlib 数据使用。

Reset 能让内存无限下降吗？

不能。它减少的是重复创建压缩器的机会，内部容量仍可能按历史峰值保留。若数据大小长期变化明显，应结合对象池大小、批次上限和内存曲线决定是否重建。

官方 API 与实现说明可参考 https://pkg.go.dev/compress/zlib 和 https://go.dev/src/compress/zlib/writer.go。