sync.Pool不能直接存局部栈分配的结构体指针，因Put会保留失效地址导致未定义行为；应堆分配或存值，并用Reset归零、判空初始化、避免小对象滥用。
为什么 sync.Pool 不能直接存结构体指针？
因为 sync.Pool 的 Put 会保留对象引用，如果存的是局部栈上分配的结构体指针（比如 &MyStruct{}），该指针可能指向已失效的栈帧，触发 undefined behavior。Go 编译器不会阻止你这么做，但运行时可能在 GC 后读到脏数据或 panic。
实操建议：
- 始终用
new(T)或&T{}在堆上分配后存入Pool，确保生命周期由 GC 管理 - 避免在闭包或 goroutine 中捕获局部变量后取其地址再放进池——哪怕看起来“没逃逸”，也难保编译器优化不改行为
- 如果结构体很小（如
struct{a,b int}），直接存值而非指针更安全；Put接收interface{}，值类型自动装箱无隐患
如何避免 sync.Pool 中的对象被意外复用？
池中对象可能被多个 goroutine 复用，且没有初始化保证。常见错误是 Put 前清空字段，但忘了某些字段（如切片底层数组未重置、map 未清空、指针字段未置 nil）导致脏数据泄露。
实操建议：
- 定义
Reset()方法显式归零状态，Put 前必须调用：obj.Reset() pool.Put(obj)
- 切片字段不要只做
obj.Slice = obj.Slice[:0]，还要检查容量是否爆炸增长——可加if cap(obj.Slice) > 1024 { obj.Slice = make([]byte, 0, 128) } - map 字段必须用
clear(obj.Map)（Go 1.21+）或遍历delete；直接赋nil会导致下次 Get 返回新 map，但旧 map 仍占内存
Get 返回 nil 怎么办？是不是 Pool 没生效？
sync.Pool.Get() 在池为空或对象被 GC 回收后返回 nil，这是正常行为，不是 bug。很多人误以为“用了 Pool 就一定有对象”，结果忘记判空直接解引用，panic。
实操建议：
- 永远按这个模式写：
v := pool.Get().(*MyType) if v == nil { v = &MyType{} } // 使用 v v.Reset() // 归零后再 Put pool.Put(v) - 不要在 Get 后立刻断言类型——如果池里混了其他类型（比如测试时误 Put 错类型），会 panic；生产环境建议用
if v, ok := pool.Get().(*MyType); !ok { v = new(MyType) } - GC 会定期清理 Pool（每次 GC 都可能清空部分或全部），所以高吞吐场景下 Get 返回 nil 的频率比预期高，别依赖“池总能命中”
为什么压测时 sync.Pool 反而比直接 new 更慢？
Pool 有锁和接口转换开销，当对象极小（如 int、struct{byte}）或单次请求只用一次时，Pool 的管理成本超过内存分配收益。另外，若 Put/Get 不成对（比如漏 Put、或 Put 前已修改字段导致无法复用），池迅速退化为“每 Get 都 new + 丢弃”，还多一层调度延迟。
实操建议：
- 只对 ≥ 32 字节、且单请求内多次复用的对象启用 Pool（如 HTTP buffer、JSON 解析器状态、数据库连接中间结构）
- 用
go tool pprof对比runtime.mallocgc和sync.(*Pool).Get的调用频次与耗时，确认是否真在减少分配 - 注意：Go 1.22 起
sync.Pool改用 per-P 本地缓存，跨 P 获取需全局锁，若 goroutine 频繁迁移 P（如大量阻塞系统调用），性能反而下降
