sync.Pool 仅在对象构造开销大且生命周期短、可安全复用时才有效；必须设 New 字段返回干净实例，Put 前重置状态，Get 后判空初始化，避免跨 goroutine 引用和误当缓存使用。
sync.Pool 什么时候用才不白忙活
绝大多数场景下，sync.Pool 不是“用了就快”，而是“用错了反而更慢”。它只在满足两个条件时才有价值：对象构造开销大（比如频繁 new(bytes.Buffer) 或解析 JSON 的结构体），且生命周期集中在单次请求/任务内、能被明确复用。HTTP 中间件、日志上下文、protobuf 解析缓冲区是典型适用场景；而全局配置对象、数据库连接、带状态的 struct 实例，一律别往里塞。
常见错误现象：sync.Pool.Get() 返回 nil 或脏数据，或压测时 GC 时间没降反升。根本原因是误把 Pool 当缓存用，或者 Put 进去的对象被外部引用未清理干净。
- 对象必须是无状态或每次 Get 后重置（比如调用
buf.Reset()） - 不能 Put 已被 goroutine 引用的对象（尤其注意闭包捕获、切片底层数组共享）
- Pool 不保证对象一定被复用，也不保证何时销毁——GC 时可能全清空
初始化 sync.Pool 必须设 New 字段
sync.Pool 的 New 字段不是可选项，是安全底线。不设会导致 Get() 在池空时直接返回 nil，后续 panic 往往发生在业务代码深处，很难定位。
正确写法是用匿名函数或工厂函数返回新实例，且确保每次返回的是干净对象：
立即学习“go语言免费学习笔记（深入）”；
var bufPool = &sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
错误写法：New: nil、New: func() interface{} { return bufPool.Get() }（递归调用）、或复用外部变量（导致状态污染）。
- 如果 New 函数执行耗时，说明对象构造本身就不适合放 Pool（比如要读文件或连 DB）
- 不要在 New 里做资源注册（如
http.DefaultServeMux.HandleFunc），Pool 可能反复调用它 - Go 1.19+ 对 New 函数做了轻量逃逸分析优化，但逻辑复杂仍建议压测验证
Put 和 Get 的顺序与时机决定性能成败
不是“用完立刻 Put”就对了。关键在：Put 必须发生在对象不再被任何 goroutine 使用之后，且越早越好；Get 后必须检查并初始化（哪怕 New 已兜底）。
典型反模式：在 defer 里 Put，但对象又被返回给上层使用；或 Get 后直接用，没清空上次残留字段。
- HTTP handler 示例中，应在写完响应后、函数返回前 Put（而非 defer）
- Put 前务必重置对象状态（
buf.Reset()、req.Header = req.Header[:0]） - Get 返回值永远要类型断言并判空：
v, ok := pool.Get().(*MyStruct); if !ok { v = &MyStruct{} } - 避免在循环内高频 Get-Put 同一 Pool（竞争激烈），可考虑 per-goroutine 子池或预分配 slice
sync.Pool 在 Go 1.21+ 的行为变化容易被忽略
Go 1.21 起，sync.Pool 默认启用 per-P（逻辑处理器）本地缓存，Get/Put 平均延迟下降，但跨 P 复用率降低。这意味着：高并发短任务（如微服务请求）受益明显；而长周期后台 goroutine 可能长期拿不到别人 Put 的对象。
无法通过配置关闭该优化，只能靠压测观察实际复用率。可通过 runtime.GC() 后检查 Pool 是否变空来粗略验证是否生效。
- 别依赖“Put 了就一定能被下次 Get 拿到”——这是最常被当真的错觉
- 监控建议：用
runtime.ReadMemStats对比开启 Pool 前后的Alloc和PauseNs，比看 QPS 更可靠 - 如果对象大小超过 32KB，会被分配到堆而非 mcache，Pool 效果急剧衰减
Pool 的边界很窄：它不解决内存泄漏，不替代对象设计，也不掩盖滥用 new 的问题。真正省下的，只是那几次 malloc 和 GC 扫描——前提是，你清楚自己在省哪一次。
