Go compress/flate Writer.Reset 的压缩器复用方案

批量压缩日志片段、消息体或独立文件时，我更愿意把“压缩器配置”和“本轮输出缓冲区”拆开处理。Go 的 compress/flate 提供了 (*flate.Writer).Reset：它会丢弃当前 writer 的运行状态，把输出目标切换到新的 io.Writer，同时沿用原来的压缩级别和预置字典。这样可以复用已经分配过的压缩器状态，但每个数据块仍然拥有独立的 DEFLATE 输出流。

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

最重要的调用约定只有一句话：当前数据写完后先检查 Close，再调用 Reset(nextDst)。Reset 不是“把未完成的数据自动保存到下一个缓冲区”，也不是并发安全的共享开关；它更像是一次带有固定配置的重新初始化。

先明确 Reset 保留和清空什么

flate.NewWriter(dst, level) 创建 writer 时会确定压缩级别，NewWriterDict 还会绑定预置字典。之后调用 Reset，官方语义是让 writer 等价于用原来的级别和字典对新 dst 重新初始化。因此可以把状态分成两类：

这也是为什么 Reset 适合“许多独立任务使用同一套压缩策略”的场景。如果每个任务都需要不同级别或不同字典，复用同一个 writer 就不再是清晰的接口设计。

按 Close 后 Reset 的顺序处理每个数据块

Write 写入的是待压缩数据，部分压缩结果可能仍在 writer 内部；Close 会把剩余内容写出并补上当前 DEFLATE 流的结束块。只有当前流完成后，才应该把 writer 指向下一个目标。

package main

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

func main() {
	// 两个输入代表两个彼此独立的压缩数据块。
	inputs := [][]byte{
		[]byte("第一批日志：用户登录成功"),
		[]byte("第二批日志：订单已提交"),
	}

	var writer *flate.Writer
	for index, data := range inputs {
		var output bytes.Buffer

		if writer == nil {
			// 只在第一次确定压缩级别，后续轮次沿用这个配置。
			var err error
			writer, err = flate.NewWriter(&output, flate.DefaultCompression)
			if err != nil {
				log.Fatal(err)
			}
		} else {
			// 上一轮已经 Close；现在让同一个 writer 写入新缓冲区。
			writer.Reset(&output)
		}

		if _, err := writer.Write(data); err != nil {
			// Write 错误表示当前输出目标没有正确接收压缩数据。
			log.Fatal(err)
		}
		if err := writer.Close(); err != nil {
			// Close 负责写出收尾数据，错误不能只靠检查 Write 来替代。
			log.Fatal(err)
		}

		fmt.Printf("第 %d 个数据块压缩后为 %d 字节\n", index+1, output.Len())
	}
}

示例里的关键点不是输出字节数，而是目标对象的生命周期：每一轮都用一个新的 bytes.Buffer 保存结果，writer 只复用压缩器本身。这样第二轮不会把第一轮的压缩流接在后面，也不会因为重建 writer 而重复分配全部内部结构。

把输出目标和 Writer 的所有权分开

如果文章、消息或文件需要保留压缩后的字节，不能让所有轮次共用同一个缓冲区。Reset 只切换 writer 的写入目标，不替调用方管理旧目标的生命周期；旧缓冲区里的字节应在切换前复制、持有或交给下游。

另一个边界是并发所有权。flate.Writer 的接口没有声明可以被多个 goroutine 同时调用。一个简单的工程约定是：一个 writer 在某个时间点只归一个压缩任务使用；并发任务各自持有 writer，或者通过串行的工作循环复用同一个 writer。

func compressMany(inputs [][]byte, level int) ([][]byte, error) {
	results := make([][]byte, 0, len(inputs))
	var writer *flate.Writer

	for _, data := range inputs {
		var output bytes.Buffer
		if writer == nil {
			// level 在整个复用周期内固定，避免调用方误以为 Reset 会换级别。
			var err error
			writer, err = flate.NewWriter(&output, level)
			if err != nil {
				return nil, err
			}
		} else {
			// 这里假设上一轮已 Close，Reset 不会替上一轮补写结束块。
			writer.Reset(&output)
		}

		if _, err := writer.Write(data); err != nil {
			// 及时返回写入错误，当前结果不进入返回列表。
			return nil, err
		}
		if err := writer.Close(); err != nil {
			// 底层输出失败可能在收尾阶段才暴露。
			return nil, err
		}

		// 复制一份结果，避免后续改动输出缓冲区时影响调用方。
		results = append(results, append([]byte(nil), output.Bytes()...))
	}
	return results, nil
}

这里的切片复制不是 Reset 的要求，而是结果所有权的选择：如果下游能在当前缓冲区生命周期内立即消费，就可以采用更低开销的所有权转移；如果返回值要长期保存，复制或使用独立的可管理对象更稳妥。

统一 Write 与 Close 的错误处理

对 bytes.Buffer 这样的内存 writer，写入通常不会失败，但真实场景可能是文件、网络连接或自定义 writer。代码至少要分别处理 Write 和 Close：

• Write 的错误表示输入没有成功进入当前压缩输出链路，应立即停止当前任务。
• Close 的错误表示压缩收尾或底层输出失败，不能因为前面的 Write 返回 nil 就忽略。
• 任何错误发生后，都不要把当前 writer 当成可直接复用的健康对象；先结束这次任务，必要时重新创建。

Flush 和 Close 也不是同一个动作。Flush 适合压缩网络协议中需要让接收方尽快看到部分数据的场景；独立数据块要交给下一个目标时，仍需要用 Close 完成当前流，再执行 Reset。

func writeBlock(writer *flate.Writer, data []byte) error {
	// 这个函数只负责当前块，不负责调用 Reset，避免混淆流的边界。
	if _, err := writer.Write(data); err != nil {
		return fmt.Errorf("写入压缩数据失败: %w", err)
	}
	if err := writer.Close(); err != nil {
		// Close 的错误必须保留底层原因，便于判断输出目标是否异常。
		return fmt.Errorf("完成压缩流失败: %w", err)
	}
	return nil
}

将“完成当前块”和“准备下一个块”拆成两个动作，调用方就能在 Close 失败时停止复用，而不是无条件继续 Reset。

按压缩级别和数据形态决定是否复用

Reset 的价值是复用已经分配的内部存储，减少重复创建压缩器的开销；它不会改变压缩算法，也不会保证所有输入形态都更快。小数据块、偶尔调用或需要频繁切换配置的场景，新增的所有权管理可能抵消收益。

可以用下面的决策表约束接口：

因此，比较复用与新建时应测量真实负载：数据块大小分布、输出目标类型、并发度、压缩级别和错误率都会影响结果。文章里的复用模式是一个明确的生命周期方案，不是脱离输入数据的性能承诺。

常见问题

Reset 会把压缩级别改成默认值吗？

不会。它沿用原 writer 的 level；如果需要另一种压缩级别，应创建新的 writer。

调用 Reset 前一定要 Close 吗？

对于要保留当前独立压缩流的场景，应先 Close。否则当前 writer 尚未完成的输出可能被丢弃，下一轮也不会替你补写上一轮的结束块。

可以把一个 flate.Writer 放进多个 goroutine 共享吗？

不应这样设计。让每个并发任务拥有自己的 writer，或把复用动作放到单线程工作循环中，所有权会更清楚。

Reset 能否同时更换压缩字典？

不能把它当成更换字典的接口。Reset 沿用原 writer 的字典；字典策略变化时重新创建 writer，并让解压端使用匹配字典。