Go sync.Pool 不能替代业务缓存的判断

sync.Pool 适合复用随时可以丢弃、重新创建的临时对象，不能承担业务缓存的按键读取、过期策略和数据保留责任。判断时先问：如果池里的对象全部消失，这次请求还能否正确完成？答案是否定的，就应该先设计明确的数据存储或业务缓存。

官方文档：https://pkg.go.dev/sync#Pool

先保护业务结果，再考虑复用对象

一份订单的计算结果、用户权限快照和配置值都有业务身份。代码需要知道读的是哪个键、是否仍有效、缺失时从哪里恢复。Pool 的 Get 没有键参数，也不会承诺取回刚刚 Put 的同一个对象。对象可以被自动移除，调用方不会得到移除通知。

JSON 编码过程中用到的空缓冲则不同：不存在旧缓冲时，创建一个新的缓冲仍能产生正确结果。这里保护的资产是最终编码结果，池只负责提供工作空间。不要把缓冲里残留的内容当作命中数据。

最小写法只复用临时缓冲

下面的独立示例复用 bytes.Buffer，并把结果复制到调用方拥有的新切片。它是实现思路示例，未附运行结果或性能承诺。

package report

import (
    "bytes"
    "encoding/json"
    "sync"
)

// 池只保存同一种临时缓冲；初始化后不再修改 New。
var buffers = sync.Pool{
    New: func() any { return new(bytes.Buffer) },
}

// EncodeJSON 返回独立的结果切片，调用方不持有池内缓冲。
func EncodeJSON(v any) ([]byte, error) {
    b := buffers.Get().(*bytes.Buffer)
    b.Reset()
    defer func() {
        // 这是单个缓冲的保留策略，不是进程总内存上限。
        if b.Cap() > 64

Encoder.Encode 会在 JSON 值后附加换行。如果接口要求没有结尾换行，应按实际输出协议调整编码方式。调用期间不要并发修改传入的数据 v；池不会给业务对象添加同步保护。

64 KiB 是示例选择的单个缓冲容量阈值，应结合实际负载调整。超过阈值时直接放弃归还，避免应用主动长期保留某个大缓冲；这既不限制池内对象数量，也不构成整个进程的内存上限。即使采用 Pool，返回值的独立切片仍然需要分配。

Pool 不提供按键、过期与命中承诺

把 map 放进 Pool，也不会让 Pool 变成按键缓存。若一次 Get 拿到的是另一张 map，或没有拿到任何旧对象，之前写入的业务值就不再可靠可见。正确结构应当先满足按键查找和缺失处理，再按需要复用其中的临时工作对象。

归还对象后的引用是主要风险入口

Pool 本身可供多个 goroutine 调用，不代表取出的 bytes.Buffer 可以被多个 goroutine 同时修改。一次借用应当对应一个清晰的使用范围：取出、重置、使用、处理输出，再归还一次。Put 之后不要继续访问该对象，也不要把同一个对象重复放入池中。

Buffer.Bytes 返回的切片与缓冲共享底层存储。若直接把它返回给上层，然后 defer Put，下一位使用者可能覆盖前一位尚未消费的数据。示例中的 copy 正是为了切断这个别名关系。仅仅 Reset 无法让旧切片获得独立存储。

还要区分逻辑清空与敏感内容处理。Reset 让缓冲长度变为零，但保留底层存储，不能据此宣称历史字节已经安全擦除。涉及口令、密钥或有隔离要求的数据时，可以直接采用不进入共享池的缓冲策略，并单独制定敏感数据生命周期。本文不提供内存安全擦除保证。

需要显式 Close 的连接、文件等资源也不能依赖池项被移除来完成清理。资源关闭必须由明确的业务生命周期负责；工作空间复用和资源管理是两个责任。

记录分配成本，不把命中当正确性条件

在业务结果保持一致的前提下，再比较不使用池与使用池时的分配次数、分配字节、延迟和堆内存峰值。应覆盖小请求、大请求和并发负载，并把输出复制的成本计入。这里列出的是测量建议，不代表本示例已经获得某个性能提升。

不要给 Pool 自行建立“命中率越高业务越正确”的目标。即使某次 Get 没复用旧对象，也只是重新分配工作空间，不能导致错误结果。若为了减少复制而改变接口为“回调期间借用缓冲”，就必须把不可保存引用的约定写进接口，并让使用范围清晰可见。

Get 后为什么还是要 Reset？

它让每次使用都从确定的空状态开始，避免依赖上一位调用方的内容。归还前 Reset 也有助于保持一致的对象状态，但不替代取出后的初始化规则。

能否依赖 Put 后下次一定 Get 到？

不能。Get 可以将池视为空，也不保证与某次 Put 对应。设置 New 后，没有可复用对象时可以创建新对象；业务逻辑必须接受这种情况。

什么时候先不用 Pool？

对象很小、分配成本不明显，或所有权约定明显增加复杂度时，可以先保留直接创建对象的实现。等有实际测量依据，再决定是否引入复用。

参考：sync.Pool 文档；Buffer.Bytes 与共享存储；Buffer.Reset。