Go sync.Pool 为什么不能当缓存：对象复用、GC 回收与生命周期验证

把 sync.Pool 当成“带自动过期的缓存”是一个很容易埋雷的判断。它适合保存短命、可重建、能降低临时分配的对象；但在垃圾回收之后，池里的对象可能全部不再可取，程序必须接受重新创建。需要稳定命中率、明确过期时间或不能丢失的数据，应该使用真正的缓存或业务存储。

先用一个请求链看懂 sync.Pool

下面的例子把 bytes.Buffer 用作短命响应缓冲区。第一次请求拿不到对象，就创建一个；写完响应后清空并放回池中，后续请求有机会复用同一个对象。

var bufferPool = sync.Pool{
    New: func() any {
        return new(bytes.Buffer)
    },
}

func render(name string) []byte {
    buf := bufferPool.Get().(*bytes.Buffer)
    buf.Reset()
    defer bufferPool.Put(buf)

    buf.WriteString("hello, ")
    buf.WriteString(name)
    return append([]byte(nil), buf.Bytes()...)
}

这里有两个容易漏掉的细节。第一，defer 只负责归还对象，不会替你清理内容，所以示例在取出后立刻调用 Reset。第二，返回值必须复制；如果直接把 buf.Bytes() 交给调用方，归还池后的下一次写入可能改掉这段数据。

升级判断：复用池和缓存不是同一种东西

把两者放在一起比较，关键不在“能不能再次取到”，而在“数据消失后是否还能接受”。

因此，池中保存一份计算结果并不能替代缓存。GC 后结果消失并不是故障，而是 sync.Pool 的设计边界。

GC 之后为什么可能取不到原来的对象

官方文档明确说明，池中的项目可能在没有通知的情况下被移除。运行时会把它视为可丢弃的临时对象集合，而不是一组必须保留的引用。下面的检查只用来验证“取不到时能否重建”，不能用来断言每次 GC 都必然清空池。

func getBuffer() *bytes.Buffer {
    value := bufferPool.Get()
    if value == nil {
        return new(bytes.Buffer)
    }
    return value.(*bytes.Buffer)
}

func main() {
    for i := 0; i 

运行后看到 0，只能说明取出的缓冲区已经被清理；它不代表对象一定来自池，也不代表 GC 一定删除了全部对象。要观察复用效果，应记录创建次数、取出次数和请求延迟，而不是读取某个对象的地址。

放回对象前，先处理三个生命周期风险

清掉上一次请求的可见状态

Buffer 要 Reset，带有 slice、map 或错误字段的结构体也要恢复到可复用初始值。清理不完整时，问题通常表现为偶发串数据，日志却很难把它和上一个请求关联起来。

限制异常膨胀的容量

某次请求可能让 Buffer 扩容到几兆字节。若把它原样放回，后续小请求会长期占着这块空间。可以按业务阈值判断：过大的对象直接丢弃，小对象才归还。

if buf.Cap() 

让类型和所有权保持单一

同一个池不要混放不同类型，也不要把归还后的对象继续交给其他 goroutine 使用。池只解决暂时的对象所有权转移，不能替代锁、队列或数据一致性方案。

用指标判断是否值得引入

先建立没有池的基线，再对比开启池后的分配次数和尾延迟。只看平均耗时容易漏掉大请求；至少同时观察 P95、P99、堆分配量和 GC 停顿。若对象创建本身很便宜，而池带来了清理复杂度和更高的 retained capacity，就没有必要保留。

一个实用的回归顺序是：固定请求体和并发数，运行基线；加入池后运行同样的压测；强制触发几轮 GC；最后把异常大对象和空池分支纳入测试。压测数据只说明这组负载，不要把一次命中率直接当成生产保证。

常见问题

sync.Pool 能不能保存登录态或查询结果？

不适合。登录态、查询结果和配置都需要明确的生命周期或一致性规则，应该交给缓存、数据库或专门的共享存储。

调用 Put 之前一定要 Reset 吗？

对 Buffer 这类带内部内容的对象，通常必须清理；是否放回则还要看容量、敏感数据和对象是否仍被其他代码持有。

GC 后池为空是不是内存泄漏？

不是。池对象可被回收是设计行为。真正需要排查的是对象没有归还、外部仍持有大容量引用，或业务把池误当成不可丢失存储。

结论：把 sync.Pool 放在“可重建对象”一侧

sync.Pool 的价值是减少高频临时对象分配，而不是提高数据命中率。只要 Get 失败时能安全创建、归还前能清理、容量有上限，且指标证明它确实降低了分配压力，就可以把它放进热点路径；其他情况宁可先保持代码简单。