Go 怎样复用 flate 编解码器减少分配

如果一个服务会反复压缩短消息，真正需要复用的不是输出缓冲，而是已经建立好的 flate.Writer。第一次用 flate.NewWriter 创建编解码器，后续把新的目标交给 Writer.Reset，就能保留压缩级别并减少重复创建对象。关键是：每一轮仍要用 Close 完成当前压缩流，不能把“复用”误解成一直向同一个流追加数据。

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

最小做法是让一个 Writer 服务于一个明确的生命周期：创建一次、每轮 Reset 到新的输出目标、写入后 Close，再决定是否放回池中。需要解压时，NewReader 返回的读取器也可以通过 flate.Resetter.Reset 切换输入流。

先判断重复创建是否已经成为成本

Reset 适合高频、短生命周期、压缩级别稳定的任务，例如批量生成小响应、把许多独立记录压缩后交给上游，或在一个 worker 中重复处理相似消息。它不是所有场景的默认优化：只压缩一次的大文件，直接创建并关闭 Writer 往往更直观；压缩级别经常变化时，也不能指望一次创建覆盖所有策略。

还要区分两个对象。bytes.Buffer 是某一轮的输出容器，flate.Writer 是持有压缩状态的编解码器。可以替换前者，也可以让 Writer 写入网络响应，但不能在上一轮尚未完成时把同一个 Writer 交给另一轮并发使用。

让 Writer 绑定可替换的输出目标

创建 Writer 时要处理可能的 level 错误；官方文档给出的合法范围是 -2 到 9。创建成功后，Reset 会丢弃上一轮的压缩状态，把 Writer 连接到新的 io.Writer，同时保留创建时的压缩级别和字典配置。

package main

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

type encoder struct {
	writer *flate.Writer
}

func newEncoder(level int) (*encoder, error) {
	// 初始化时只建立一次压缩器；非法 level 应立即返回给调用方。
	w, err := flate.NewWriter(nil, level)
	if err != nil {
		return nil, err
	}
	return &encoder{writer: w}, nil
}

func (e *encoder) encode(dst *bytes.Buffer, text []byte) error {
	// Reset 只替换本轮输出目标，不改变创建时的压缩级别。
	e.writer.Reset(dst)
	if _, err := e.writer.Write(text); err != nil {
		return err
	}
	// Close 会写出当前 DEFLATE 流的收尾数据；不能省略。
	return e.writer.Close()
}

func main() {
	enc, err := newEncoder(flate.DefaultCompression)
	if err != nil {
		panic(err)
	}

	var first, second bytes.Buffer
	if err := enc.encode(&first, []byte("first message")); err != nil {
		panic(err)
	}
	if err := enc.encode(&second, []byte("second message")); err != nil {
		panic(err)
	}
	fmt.Println(first.Len() > 0, second.Len() > 0)
}

这里的 NewWriter(nil, level) 只把初始目标留空，随后在每次 encode 中通过 Reset 指定实际目标。Close 之后，下一轮仍然可以再次 Reset；它结束的是当前数据流，不是 Go 对象本身的可复用资格。

把 Reset、Flush 和 Close 分工

Reset 是切换目标并清理上一轮状态；Flush 是把当前压缩数据尽快推给底层 Writer，适合需要分段发送的协议；Close 则负责写出当前流的结束信息并关闭 Writer。普通的“每条消息得到一段完整压缩数据”场景，应该在写完后调用 Close，而不是只调用 Flush。

如果底层目标是网络响应，Flush 的意义是让数据尽早离开压缩层，但它产生的是同步刷新标记，并不等同于结束一个独立的 DEFLATE 流。若接收方需要逐条独立解码，就要先设计好消息边界，不能靠重复 Flush 猜测边界。

把复用对象放进池时，先完成当前流

池化的边界应该在“当前压缩流完成”之后。典型顺序是：从池取出 Writer，Reset 到本轮目标，Write，必要时 Flush，Close，清理或替换过大的输出缓冲，最后再放回池。任何 Write 或 Close 错误都应让对象退出池，避免把底层写入失败后的不确定状态带给下一轮。

package main

import (
	"bytes"
	"compress/flate"
	"sync"
)

var writerPool = sync.Pool{
	New: func() any {
		// 池中对象统一使用同一个级别，避免取出后无法改变 level。
		w, err := flate.NewWriter(nil, flate.BestSpeed)
		if err != nil {
			panic(err)
		}
		return w
	},
}

func compressMessage(input []byte) ([]byte, error) {
	dst := new(bytes.Buffer)
	w := writerPool.Get().(*flate.Writer)
	w.Reset(dst)

	if _, err := w.Write(input); err != nil {
		// 当前 Writer 可能已处于异常状态，不再放回池中。
		return nil, err
	}
	if err := w.Close(); err != nil {
		// Close 失败同样不能把对象交给下一次任务。
		return nil, err
	}
	writerPool.Put(w)
	return append([]byte(nil), dst.Bytes()...), nil
}

示例只展示池化边界，没有宣称任何固定的分配收益。实际是否值得池化，应结合任务大小和基准测试判断。特别要留意 bytes.Buffer 会保留容量：如果偶尔压缩过一个异常大的消息，直接把它长期放在共享池里，可能让常规请求一直背着大容量。

需要解压时复用 Reader

flate.NewReader 返回的是 io.ReadCloser，这个返回值同时实现了 flate.Resetter。拿到接口后，可以用 Reset(reader, nil) 切换到底层的新输入流；该方法返回错误，因此不能像 Writer.Reset 一样忽略结果。读完当前数据后要调用 Close，再决定是否复用。

package main

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

func readTwoStreams(first, second []byte) error {
	reader := flate.NewReader(bytes.NewReader(first))
	resetter, ok := reader.(flate.Resetter)
	if !ok {
		// 当前实现没有提供 Resetter 时，保留一次性读取路径。
		_ = reader.Close()
		return io.ErrUnexpectedEOF
	}

	if _, err := io.Copy(io.Discard, reader); err != nil {
		_ = reader.Close()
		return err
	}
	if err := resetter.Reset(bytes.NewReader(second), nil); err != nil {
		_ = reader.Close()
		return err
	}
	_, err := io.Copy(io.Discard, reader)
	closeErr := reader.Close()
	if err != nil {
		return err
	}
	// 关闭错误也要返回，不能因为读取已完成就吞掉资源错误。
	return closeErr
}

示例中的类型断言主要是为了展示接口边界；标准库 NewReader 返回的读取器实现了 Resetter。如果代码把读取器存成更窄的接口，复用前需要保留或重新断言这个能力。字典场景还要保持字典一致，不能把带字典的流重置到不匹配的解码条件。

哪些对象适合放入池

可以把选择压缩级别、Writer 是否独占、输出缓冲上限和错误淘汰策略一起写进池化约定。下面这张速查表比“看到 Reset 就全部池化”更稳妥：

常见问题

调用 Reset 后还需要 Close 吗？需要。Reset 只切换到新的输出目标；当前轮写入完成后仍要 Close，才能完成该轮压缩流。

Flush 能不能代替 Close？通常不能。Flush 适合把暂存数据推向底层，Close 才负责当前流的结束收尾；两者职责不同。

Writer.Reset 能修改压缩级别吗？不能。Reset 保留创建 Writer 时的 level；如果策略确实变化，应重新创建对应级别的 Writer，或按级别分别维护池。

池化后为什么仍然可能占用很多内存？因为编解码器和输出缓冲可能保留历史容量。对异常大输入设置淘汰规则，并避免把带有巨大容量的缓冲长期共享。

Reader 也一定能复用吗？标准库 NewReader 返回的读取器实现了 flate.Resetter，但代码仍应按接口检查并处理 Reset 错误；不要把任意 io.ReadCloser 都假设成可重置。

速查：Writer 创建一次，按轮次 Reset 到新目标；独立压缩结果用 Close 收尾，需要即时发送才考虑 Flush；池化前淘汰异常状态和异常大缓冲；Reader 复用则通过 flate.Resetter.Reset 切换输入并检查错误。