Go sync.Pool 使用边界：复用临时对象降低分配

sync.Pool 适合复用短生命周期、可重置、创建成本较高的临时对象，比如 bytes.Buffer、编码缓冲区或临时结构。它不是缓存，也不适合保存业务状态。

Pool 会被 GC 清理

sync.Pool 里的对象可能在任意 GC 后被清空，所以不能依赖它保存必需数据。正确心态是：拿到对象是收益，拿不到也能正常创建。

Put 前必须重置

对象放回池子之前要清理旧内容，否则下一次使用可能带出脏数据。对于 buffer，要 Reset；对于结构体，要清空引用字段，避免延长对象生命周期。

先证明分配压力

sync.Pool 会增加代码复杂度，也可能带来错误复用。只有在 profile 和 benchmark 都证明临时对象分配显著时，才建议引入。

生产场景

适用于高频 JSON 编码、日志格式化、协议拼包、压缩缓冲和临时 byte buffer。

关键指标

• allocs/op 和 B/op 下降幅度
• GC CPU 与 pause 变化
• Pool 对象错误复用次数

常见误区

• 把 sync.Pool 当 LRU 缓存
• Put 前不清理引用字段
• 低频路径也强行引入 Pool

代码示例

buf := pool.Get().(*bytes.Buffer)
buf.Reset()
defer pool.Put(buf)
// 不要把请求上下文或业务状态放进 Pool

上线检查

• 优化前后必须保留同一条件下的 benchmark 或 profile。
• 至少观察 P95/P99、错误率、CPU、内存和 GC 指标。
• 如果改动影响热路径，必须准备灰度和回滚方案。