sync.Pool 不能直接存 *Object 是因为复用时字段残留旧值，必须在 Get 后调用 Reset() 清理；Put 前需确保无并发访问，避免逃逸和内存泄漏，且仅在高频短生命周期场景下才优于 new。
为什么 sync.Pool 不能直接存 *Object 而要小心零值问题
因为 sync.Pool 不保证对象复用时的初始状态，放进去的 *Object 可能被 GC 清理或重用时残留旧字段值。常见错误是：构造后直接 pool.Put(obj)，下次 Get() 拿到的 obj 字段还是上次用过的脏数据，比如 obj.id 是上一个请求的 ID，obj.buf 里还躺着旧的 JSON 字节。
- 必须在
pool.Get()后手动重置字段，不能依赖构造函数 - 推荐把重置逻辑封装成
(*Object).Reset()方法，而不是每次 Get 后手写赋值 - 如果
Object包含指针字段（如*bytes.Buffer），Reset 时要避免内存泄漏——比如先buf.Reset()而不是直接obj.buf = nil
如何用 sync.Pool 正确管理 *Object 生命周期
关键不是“存指针”，而是控制对象创建、复用、归还三阶段的边界。Go 的 sync.Pool 本身不持有所有权，它只缓存，不管理内存生命周期；真正决定对象生死的是你调用 Get() 和 Put() 的时机。
-
New函数只在池空时触发，应返回全新初始化的&Object{}，不要复用已有实例 -
Put()前必须确保该*Object不再被其他 goroutine 使用（即无并发读写），否则可能引发 data race - 不要在 defer 中无条件
Put()—— 如果对象被提前 return 或 panic，defer 可能拿到已失效的指针 - 示例：
obj := pool.Get().(*Object)<br>obj.Reset() // 必须重置<br>// ... use obj<br>pool.Put(obj) // 归还前确保没逃逸、没被其他 goroutine 持有
*Object 在 sync.Pool 里逃逸了怎么办
如果 *Object 被编译器判定为逃逸，会绕过栈分配走堆，导致 GC 压力上升，抵消池带来的收益。典型逃逸场景是：把 *Object 传给接口参数、赋值给全局变量、或作为返回值传出函数作用域。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
go tool compile -gcflags="-m"检查是否逃逸，重点关注"... escapes to heap"提示 - 避免在
Get()后立即转成interface{}或塞进 map/slice（除非明确需要） - 如果
Object很小（比如只有几个 int/bool 字段），考虑不用指针，直接存Object值类型 ——sync.Pool对值类型同样有效，且无 nil 解引用风险 - 若必须用指针，确保其字段不含大数组或未限制长度的 slice（否则每次 Reset 都可能保留大量内存）
为什么有时 sync.Pool 比直接 new(Object) 还慢
池不是银弹。当对象分配频率低、生命周期长、或竞争激烈时，池的锁和查找开销反而更高。尤其在高并发下，多个 P 竞争同一个池的本地队列，可能触发跨 P 迁移，带来额外 cache miss。
立即学习“go语言免费学习笔记（深入）”；
- 用
pprof对比runtime.mallocgc和sync.(*Pool).Get的调用频次与耗时 - 如果单次请求只用 1–2 个
*Object，且Object构造成本极低（比如无系统调用、无 malloc），池收益几乎为零 - 注意 Go 1.21+ 对
sync.Pool做了本地化优化，但前提是你的 workload 符合“短生命周期 + 高频复用”模式 - 别为了“用池”而用池——真正卡点通常是序列化、网络、锁，不是对象分配本身
make([]byte, 0, 1024)），等于变相 new。这得靠压测 + pprof 看 allocs/op 和 pause 时间来调。 
