Go compress/flate 怎样复用 Writer 减少压缩分配

如果一段服务代码反复调用 flate.NewWriter，压缩结果通常没有问题，但高频请求会不断创建压缩器及其内部状态。更合适的做法是固定压缩级别，提前创建一个 Writer 放进 sync.Pool，每次取出后用 Reset 指向新的输出缓冲，写完调用 Close，最后归还池中。

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

这里的关键不是让一个 Writer 同时服务所有请求，而是让每个请求在自己的租用期间独占一个 Writer。池化只复用对象，不改变并发隔离边界。

先理解 NewWriter 与 Reset 的差别

NewWriter 会创建新的压缩器，并固定本次 Writer 的压缩级别；Reset 则丢弃上一轮的工作状态，把同一个 Writer 重新绑定到新的 io.Writer。因此复用时通常只在压缩级别不变的任务之间进行。

package main

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

func compressOnce(zw *flate.Writer, input []byte) ([]byte, error) {
    var out bytes.Buffer
    // Reset 只切换输出目标；这一轮的结果由新的 out 独立承载。
    zw.Reset(&out)
    if _, err := zw.Write(input); err != nil {
        return nil, fmt.Errorf("写入压缩器失败: %w", err)
    }
    // Close 会刷新尾部数据；省略它可能得到不完整的 DEFLATE 流。
    if err := zw.Close(); err != nil {
        return nil, fmt.Errorf("关闭压缩器失败: %w", err)
    }
    return append([]byte(nil), out.Bytes()...), nil
}

func main() {
    zw, err := flate.NewWriter(io.Discard, flate.DefaultCompression)
    if err != nil {
        log.Fatal(err)
    }
    first, err := compressOnce(zw, []byte("first payload"))
    if err != nil {
        log.Fatal(err)
    }
    second, err := compressOnce(zw, []byte("second payload"))
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(len(first), len(second))
}

示例里把结果复制出来，是为了让下一次 Reset 不会覆盖上一轮的缓冲。如果业务直接把结果写入网络或文件，也可以让输出目标由调用方管理，但必须在 Writer 结束后再使用完整结果。

用 sync.Pool 复用 Writer

服务端通常不需要自己维护固定数量的压缩器，sync.Pool 可以保存暂时不用的对象。池中的 Writer 必须在借出后完成一整轮压缩，不能把仍在使用的 Writer 放回池里。

package compresspool

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

var writerPool = sync.Pool{
    New: func() any {
        // 池只创建固定压缩级别的 Writer，后续通过 Reset 换输出。
        zw, err := flate.NewWriter(nil, flate.BestSpeed)
        if err != nil {
            panic(fmt.Sprintf("创建 flate.Writer 失败: %v", err))
        }
        return zw
    },
}

func Compress(input []byte) ([]byte, error) {
    zw := writerPool.Get().(*flate.Writer)
    defer writerPool.Put(zw) // 归还发生在 Close 完成之后，避免并发复用。

    var out bytes.Buffer
    zw.Reset(&out)
    if _, err := zw.Write(input); err != nil {
        return nil, fmt.Errorf("压缩写入失败: %w", err)
    }
    if err := zw.Close(); err != nil {
        return nil, fmt.Errorf("压缩关闭失败: %w", err)
    }
    // 脱离 out 的底层数组，避免调用方看到下一轮 Reset 的变化。
    return append([]byte(nil), out.Bytes()...), nil
}

这个实现把池化对象的生命周期压缩在一个函数里：Get 后立即取得独占权，Reset 绑定当前输出，Close 刷新完成后由 defer 归还。若返回值长期保存，复制结果也比把 bytes.Buffer 本身暴露给调用方更稳妥。

为什么必须处理 Close、输出和错误路径

flate.Writer 是流式写入器，Write 返回并不代表尾部已经全部写到目标中。Close 会刷新剩余数据；如果底层输出返回错误，错误也应该继续向调用方传播。

如果输出目标是网络连接，通常不需要复制到新的字节切片，但要让 Writer 的独占范围覆盖完整的写入和关闭过程；如果输出目标是可复用的内存缓冲，则要明确谁负责读取、清空和持有它。

并发场景下怎样保持隔离

复用并不等于共享。一个 *flate.Writer 在同一时间只能被一个压缩任务使用。正确的并发模型是每个请求从池里取得一个对象，完成整轮写入后再归还；请求之间共享的是池，而不是 Writer 实例。

如果压缩任务本身跨越多个异步回调，不能在中间把 Writer 放回池中；否则另一个请求可能拿到同一对象，导致两条 DEFLATE 流交错。需要跨阶段传递时，可以把压缩动作封装成同步函数，或显式传递一个仅属于当前任务的租约对象。

小结：什么时候值得复用

• 请求频率高、输入大小相近，并且性能分析确实显示压缩器分配明显时，优先使用 Reset + sync.Pool。
• 每轮都要重新绑定输出目标，并在 Close 后检查错误；返回内存结果时按需复制。
• 不要为了少一次分配而共享同一个 Writer；池化的最小单位是一次独占使用。

常见问题

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

不需要。Writer 保留创建时的压缩级别和字典配置，Reset 主要切换新的输出目标并清理上一轮状态。需要不同级别时，应分别建立不同的池。

为什么不能直接把 bytes.Buffer.Bytes() 返回出去？

如果缓冲的底层数组后续还会被复用，调用方持有的切片可能被下一轮写入影响。结果需要跨越当前函数生命周期时，复制一份更安全。

sync.Pool 能保证对象一定还在吗？

不能。它适合保存可重建的临时对象，池可能在运行时清空。因此 New 函数必须始终能够创建一个可用的 Writer，业务不能把池当作永久缓存。