sync.Pool.Get可能返回nil是正常设计行为，因GC会清空未引用对象、goroutine迁移导致本地池遗弃、P被抢占触发慢路径；必须显式判空并兜底构造，不可直接类型断言。
sync.Pool.Get 为什么可能返回 nil
sync.Pool.Get 不保证返回非 nil 值，它只返回“上次 Put 进去的、尚未被 GC 清理的对象”，也可能返回 nil（比如池为空、或对象已被清理）。高频场景下如果直接 Get 后就用，不判空，会 panic 或逻辑错。常见错误是写成：
obj := pool.Get().(*MyStruct)<br>obj.Reset()——一旦
Get 返回 nil，(*MyStruct)(nil) 强转立即 panic。
正确做法始终带判空 + 构造兜底：
- 先
Get，检查是否为 nil - 为 nil 时手动 new / make 一个新对象
- 不要在
Get后直接类型断言，先用if obj != nil分支隔离
Put 的对象必须是 Get 同一批构造逻辑产出的
sync.Pool 不做类型校验，但 Put 错对象会导致后续 Get 行为不可控。典型错误：在 HTTP handler 中 Put 一个刚 new 出来的临时对象，而该对象没经过 Get 流程，也没复用 Reset 逻辑；或者 Put 了部分字段未清零的对象，下次 Get 出来时残留脏数据。
高频复用下必须统一生命周期管理：
立即学习“go语言免费学习笔记（深入）”；
- 所有 Put 前必须调用
Reset()方法（或等价清零逻辑） -
Reset()要覆盖所有可变字段，包括嵌套 struct、slice 底层数组指针、map 等（map不能直接赋nil，得用clear()或重新 make） - 避免在 Put 前做深拷贝、序列化、IO 等重操作——Put 只应是“归还”动作
高频场景下 Pool 的性能拐点在哪
sync.Pool 在 goroutine 局部缓存（private）、共享池（shared）之间做平衡，但不是越用越快。当单个 goroutine 每秒 Get/Put 超过 10⁵ 次，且对象 size > 1KB 时，容易触发 shared 队列锁竞争或 GC 扫描开销上升，反而比直接 new 慢。
实测建议关注三点：
- 对象 size 控制在 64B–512B 区间最友好（避开 tiny alloc 和 large alloc 分界）
- 避免跨 goroutine 频繁 Put（比如从 worker goroutine Put 到 main goroutine 创建的 Pool）——Pool 绑定到创建它的 P，跨 P Put 会进 shared 队列，加锁
- 用
go tool trace观察runtime.gcStopTheWorld和runtime.mallocgc占比，若 GC 时间占比反降但 CPU time 上升，大概率是 Pool 内部 lock contention 或 false sharing 导致
sync.Pool 无法替代内存逃逸分析
很多人想用 Pool “绕过逃逸”，但 Go 编译器对 Get 返回值仍做逃逸分析：只要该对象被传给任何形参为 interface{} 或泛型约束的函数，或被闭包捕获，就会逃逸到堆——Pool 只是复用堆对象，不改变逃逸结果。
真正影响性能的是分配频次与 GC 压力，不是“堆 vs 栈”。所以：
- 别为了“避免逃逸”硬套 Pool；先用
go build -gcflags="-m"确认对象是否真逃逸、逃逸原因 - 如果对象本身逃逸不可避免（如作为 map value、channel element），Pool 才有意义；否则栈上分配更快
- 注意
Put后对象仍可能被 GC 清理——Pool 不是强引用，GC 会定期 sweep，依赖它长期持有状态会出错
Get/Put 次数更重要。 
