sync.Pool适用于高频创建/销毁、构造开销大的短生命周期对象（如*bytes.Buffer），不适用于小对象、单次使用对象或含外部资源/未清零字段的对象。
sync.Pool 什么时候该用，什么时候不该用
绝大多数情况下，sync.Pool 不是你需要的“性能优化手段”，而是为特定高频、短生命周期、构造开销大的对象兜底的缓存机制。它不是通用对象复用方案，也不是替代 make 或结构体字面量的理由。
常见误用场景：给 string、int、小切片（如 []byte{}）套 sync.Pool —— 反而增加 GC 压力和锁竞争。Go 运行时对这类小对象已有高效分配器。
- 适合：HTTP 中的
*bytes.Buffer、自定义解析器中的Tokenizer、频繁分配的临时[][]byte缓冲区 - 不适合：单次请求中只用一次的对象、带外部资源（如文件句柄、DB 连接）的对象、含未清零字段且逻辑依赖初始值的对象
- 关键判断点：对象初始化耗时是否显著？是否在 goroutine 高频创建/丢弃（比如每毫秒上百次）？是否能安全复用（即 New 函数返回的对象可被 Reset）？
New 字段必须返回可安全复用的干净对象
sync.Pool 的 New 字段不是“构造函数”，而是“兜底工厂”——当池空时调用它拿新对象；但池中取出的对象，你必须自己负责归零或重置。Go 不会帮你调 Reset()，也不会检查字段是否残留旧数据。
典型错误：定义 Pool 时只写 New: func() interface{} { return &MyStruct{} }，却在 Get() 后直接使用未清零的字段，导致脏数据泄露。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：让类型自带
Reset()方法，并在Get()后显式调用；或在New中返回已初始化好默认值的对象 - 危险模式：把含指针、map、slice 字段的结构体丢进池，却不重置这些字段 → 下次
Get()可能拿到残留的 map 数据或 slice 底层数组 - 示例：
var bufPool = sync.Pool{New: func() interface{} { return new(bytes.Buffer) }}是安全的，因为bytes.Buffer的Reset()是幂等的；但若你自己写的结构体没实现类似逻辑，就别这么干
Put 和 Get 的调用时机直接影响效果和内存泄漏
Put() 不是“释放”，而是“建议放回池”；Get() 也不保证一定从池取——如果池空或 GC 正在清理，它会调 New。更关键的是：Put 太早或太晚都会破坏池的稳定性。
常见错误现象：runtime: mark sweep GC freed X objects, but pool swept Y 日志频繁出现，说明对象刚 Put 就被 GC 扫掉，池基本没起作用。
- Put 太早：比如在 goroutine 开头
buf := bufPool.Get().(*bytes.Buffer); defer bufPool.Put(buf)—— 若后续逻辑 panic 或提前 return，Put永远不执行，对象泄漏 - Put 太晚：在函数末尾统一 Put，但中间多次
Get()又不Put()，导致池中对象数长期为 0 - 推荐节奏：每个逻辑单元（如一次 HTTP handler 执行）内，
Get一次，用完立刻Put；避免跨 goroutine 共享同一个池对象（即使类型相同）
sync.Pool 在 Go 1.21+ 的 GC 行为变化要特别注意
从 Go 1.21 开始，sync.Pool 对象不再严格按“上次使用时间”保留，GC 会更积极地清理长时间未被 Get 的池中对象。这意味着：依赖“池能长期缓存”的代码，在升级后可能突然变慢。
典型表现：压测时 QPS 下降、CPU 升高，pprof 显示 runtime.mallocgc 占比上升，而 sync.Pool.Get 调用次数激增。
- 验证方式：运行时加
GODEBUG=gctrace=1，观察 GC 日志中pool sweeps是否频繁 - 缓解思路：适当增大对象复用粒度（比如把多个小 buffer 合并为一个大 buffer 池），或改用更可控的 arena 分配（如
go.uber.org/zap的bufferpool） - 不要依赖池中对象存活超过单次请求生命周期——这是最常被忽略的隐含假设
