sync.Pool 中对象会在每次 GC 前被运行时强制清空，无法手动回收或按需驱逐；Put 前必须显式 Reset，New 函数须返回无副作用的新实例，仅适用于短生命周期小对象。
Go 的 sync.Pool 不提供手动“回收”接口，也不支持按需清空或逐个驱逐对象；它的清理完全由运行时控制——每次 GC 前自动调用 poolCleanup，清掉所有池中对象。你无法干预这个时机，也不能假设某个 Put 进去的对象能活过下一次 GC。
为什么 sync.Pool 里的对象会突然消失？
因为 Go 运行时在每次垃圾回收（GC）前，会强制遍历所有注册的 sync.Pool 实例，把它们的本地池和全局池全部置空。这不是“懒清理”，而是硬性策略：只要 GC 触发，池就清零。这意味着：
-
Get返回的对象可能来自上一轮 GC 后新New出来的，也可能是刚被其他 P “偷走”又放回的，但绝不是“长期驻留”的缓存 - 如果你依赖池中对象保持某种状态（比如预填充的 map 字段），它大概率在下次
Get时已失效或被重用为脏数据 - pprof 中观察
/debug/pprof/heap?gc=1可验证：池对象只出现在 allocs 统计里，不出现在 live heap 中
Put 之前必须 reset，否则下次 Get 就是脏数据
池不负责重置对象状态，Put 只是把指针丢回队列。常见错误是直接 Put 一个未清理的 *bytes.Buffer 或自定义结构体：
buf := bufPool.Get().(*bytes.Buffer)
buf.WriteString("hello") // 写入内容
bufPool.Put(buf) // ❌ 忘了 Reset，下次 Get 到的 buf 仍含 "hello"
正确做法是每次使用后显式清理：
立即学习“go语言免费学习笔记（深入）”；
- 对
bytes.Buffer：调用buf.Reset()（清长度、保留底层数组） - 对
[]byte：用buf = buf[:0]截断长度，不能只nil掉变量 - 对结构体：逐字段赋零值，或提供
Reset()方法并统一调用
New 函数必须返回全新实例，且不能带副作用
New 是兜底工厂，不是初始化钩子。它会在任意 goroutine 中被并发调用，因此：
- 禁止复用全局变量（如
return &globalBuf），会导致多 goroutine 竞态写同一内存 - 禁止做耗时操作（如打开文件、HTTP 请求），它可能卡住整个
Get路径 - 必须预分配容量（如
make([]byte, 0, 1024)），否则每次Get后扩容就失去复用意义 - 返回值类型要和
Get后的类型断言一致，否则 panic（如Get().(*MyStruct)要求New返回&MyStruct{}）
大对象、有状态对象、外部资源一律禁用 Pool
sync.Pool 只适合高频分配、短生命周期、纯内存的小对象（典型尺寸
- 数据库连接、文件句柄、net.Conn：Pool 不关闭资源，也不会感知生命周期，必然泄漏
- 含未重置指针字段的结构体：旧指针可能指向已释放内存，引发 panic 或静默数据污染
- 超过几 KB 的切片或结构体：增大 GC 扫描压力，反而拖慢整体性能
- 需要精确控制存活时间的对象（如 session 缓存）：Pool 的 GC 驱逐不可控，语义不符
真正关键的一点是：Pool 的价值不在“缓存”，而在“分摊分配开销”。如果单次请求只用一两次对象，引入 Pool 反而增加调度和 TLS 查找成本；只有当对象分配频次远高于 GC 频次（比如每秒万级 buffer 分配），收益才明显。别把它当成通用对象池来用。
