sync.Pool适合复用创建开销大、生命周期短、可安全复用的对象，如预分配的[]byte、bytes.Buffer、json.Decoder等；不适合小对象、带状态struct、含外部引用或需确定性销毁的对象。
sync.Pool 适合复用什么类型的对象
不是所有对象都值得放进 sync.Pool，它只对「创建开销大 + 生命周期短 + 可安全复用」的对象有效。比如 []byte 缓冲区、json.Decoder 实例、自定义结构体（不含指针到外部堆内存）。常见误用是把带状态的 struct（如含未清空 map 或 channel）直接放进去，下次 Get 到的可能是脏数据。
- 推荐：预分配的
[]byte、临时bytes.Buffer、解析器/序列化器实例 - 危险：含未重置字段的 struct、持有闭包或 goroutine 引用的对象
- 无效：小而轻量对象（如
int、string），Pool 开销反而更高
Put 和 Get 的调用时机必须匹配
对象必须在「确定不再使用后」才调用 Put，且不能跨 goroutine 共享同一个实例。常见错误是 Put 早于实际使用完成，或在 defer 中无条件 Put 导致重复释放。
- 正确做法：在函数末尾、资源真正释放后 Put，例如 HTTP handler 中 write 完成后
- 典型坑：
defer pool.Put(buf)放在函数开头，但 buf 后续被写入并返回给 caller，造成 use-after-free - 注意：Get 返回的可能是 nil，需判空；Put 接收 nil 不 panic，但无意义
Pool 新对象构造函数 New 不会自动调用
sync.Pool 的 New 字段只是兜底工厂，仅当池为空时触发。它不会在每次 Get 时调用，也不会保证调用次数可控。依赖 New 做资源初始化（如打开文件、建连接）极易泄漏。
- 安全做法：
New只做纯内存分配，如func() interface{} { return make([]byte, 0, 1024) } - 禁止行为：
New中调用os.Open、sql.Open等有副作用的操作 - 性能提示：New 函数本身不加锁，但若内部有同步逻辑（如 sync.Once），可能成为瓶颈
Pool 没有全局清理机制，对象可能长期滞留
sync.Pool 在 GC 时会清空所有私有缓存（per-P），但共享池部分只在下一次 GC 前随机丢弃，且不保证及时性。这意味着高峰后大量对象不会立刻回收，可能掩盖内存泄漏。
立即学习“go语言免费学习笔记（深入）”；
- 现象：压测后 RSS 居高不下，pprof 显示大量
[]byte占用堆，但代码里明明 Put 了 - 原因：Pool 不是内存管理器，它只为降低 GC 频率，不提供确定性生命周期控制
- 对策：关键对象（如大 buffer）建议设 size 上限，或配合手动 reset + 复用逻辑，而非完全依赖 Pool 自动管理
最常被忽略的一点：Pool 的收益高度依赖实际分配频率和对象大小。压测前先用 runtime.ReadMemStats 对比 GC 次数和 pause 时间，别只看代码“用了 Pool”就以为优化到位。
