Go sync.Pool避免把长期状态放进 Pool的设计边界

Go sync.Pool 的核心不是“长期缓存”，而是暂存一批可以随时丢弃、下次重新创建的临时对象。判断一个对象能不能放进 Pool，可以先问一句：即使它现在被垃圾回收，业务是否仍能从零构造出等价对象？如果答案是否定的，就不要把它放进 Pool。

配置、数据库连接、租户信息、权限快照、带业务语义的缓存条目，都应该由明确的所有者管理。bytes.Buffer、临时编码器、短生命周期的切片容器则更符合 Pool 的用途。官方文档也明确说明，Pool 中的项目可能在没有通知的情况下被自动移除，Get 不能保证取回某一次 Put 放入的值。

最稳妥的设计是：Pool 只保存“可重置、无身份、可丢弃”的工作对象；长期状态放在请求对象、服务对象或专门的缓存/连接池中。

先用可丢弃性划出边界

把对象分成两类会比较清楚。临时对象只承载本次调用的中间数据，丢失后重新分配不会改变业务结果；长期状态则包含外部身份、共享资源或下一次调用必须继续使用的信息。后者即使实现了 sync.Pool 的并发安全，也仍然不适合放入 Pool，因为 Pool 的存活时间和容量都不提供业务保证。

例如，把“当前租户 ID”和“当前请求的权限”写进一个复用结构体，下一次 Get 可能得到上一请求留下的字段。即便每次都能取到对象，这种状态串用也会把对象复用问题变成权限和数据隔离问题。

让 Pool 只保存可重置对象

Pool 的典型用法是让 New 返回指针，在借出后先清空，再在归还前完成必要的重置。重置逻辑要覆盖会影响下一次调用的字段，而不是只清理长度字段。

package main

import (
    "bytes"
    "sync"
)

var bufferPool = sync.Pool{
    New: func() any {
        // 返回指针便于复用同一个可变缓冲区。
        return new(bytes.Buffer)
    },
}

func encodeLine(prefix, value string) []byte {
    buf := bufferPool.Get().(*bytes.Buffer)
    // 借出后先清掉上一次调用残留的内容。
    buf.Reset()
    buf.WriteString(prefix)
    buf.WriteByte('=')
    buf.WriteString(value)

    // 复制结果后再归还，避免调用方继续引用池内可变对象。
    result := append([]byte(nil), buf.Bytes()...)
    bufferPool.Put(buf)
    return result
}

这里返回的是独立切片，调用方不再依赖 Pool 内的 Buffer。若对象带有 map、切片、错误信息或上一次请求的标签，就需要在归还前逐项清理；无法可靠清理时，宁可不复用。

把长期状态移到明确的所有者

一个实用的拆分方式是让服务对象持有长期依赖，让每次调用单独拥有请求状态，Pool 只提供中间产物。比如连接池负责连接生命周期，配置对象负责版本和刷新，权限对象负责授权判断；临时编码缓冲区只负责拼装本次输出。

Put 前后的安全检查清单

归还前检查四件事：第一，是否清理了所有业务字段；第二，返回值是否已经脱离池内对象；第三，对象是否会被多个 goroutine 同时使用；第四，Pool 是否被复制。sync.Pool 可以被多个 goroutine 并发调用，但 Pool 第一次使用后不能复制；它也不承诺容量、命中率和对象一定存活。

如果复用后收益很小，或对象属于短命对象自己的局部空闲链表，直接分配往往更简单。上线前可以围绕分配次数、GC 压力和请求延迟做基准测试，但不要把某一次 Get 命中当作业务正确性的前提。

常见问题

sync.Pool 会不会把对象永久保存？不会。对象可能自动被移除，Pool 只适合作为分配压力的缓冲，不是可靠缓存。

调用 Put 前只调用 Reset 够吗？只有对象全部状态都在 Reset 中清理时才够。自定义结构体还要清除 map、切片引用和请求元数据，并确认调用方不再持有可变引用。