sync.Pool仅适用于创建开销大、生命周期短且可安全重置的临时对象；Get后必须手动Reset，New须返回干净实例，否则易致脏数据、内存泄漏或竞态。
sync.Pool 不是对象池模式的通用解，它只在特定条件下有效——对象创建开销大、生命周期短、能被安全重置。盲目套用反而增加 GC 压力、引发脏数据或竞态。
sync.Pool.Get() 返回 nil 或脏数据怎么办
这是最常踩的坑：Get() 可能返回上次 Put() 进去的旧对象（字段值全残留），也可能返回 nil（池空且没设 New）。Go 从不帮你清零，也不兜底初始化。
- 每次
Get()后第一件事必须是重置：对*bytes.Buffer调buf.Reset()；对自定义结构体，必须提供幂等的Reset()方法并立即调用 -
New字段不是可选项，必须设，且只能返回干净实例：比如func() interface{} { return &MyStruct{} }，不能复用全局变量或带副作用（如打开文件） - 别在
defer里无条件Put()：如果Get()返回nil，Put(nil)合法但无意义；更糟的是 panic 导致Put()漏掉，对象永久泄漏
自定义结构体 Put 前不清空指针字段会怎样
结构体里有 data []byte、cache map[string]int 或 ch chan int？直接 Put() 就等于把引用“钉”在池里——GC 看到这些指针还活着，就不会回收底层数组或 map 的内存，最终 RSS 暴涨。
- 切片字段必须用
s = s[:0]截断长度，不能s = nil（后者丢掉底层数组，失去复用价值） - map 字段要遍历
delete()或复用底层数组（如for k := range m { delete(m, k) }） - channel 字段必须
close()后置为nil，否则下次Get()到的 channel 仍可读写，引发不可预测行为 - 所有导出/未导出的可变字段都得归零，
Reset()方法里别漏掉id、ts、err这类标量
为什么高并发下 sync.Pool 命中率骤降
根本原因在运行时设计：sync.Pool 按 P（逻辑处理器）维护本地缓存，对象 Put() 后大概率留在当前 goroutine 所在的 P 里；一旦 goroutine 被调度到别的 P（比如阻塞后唤醒），就拿不到之前放进去的对象。GC 时 victim cache 还会被清空。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 命中率低 ≠ 完全失效，它只是退化为“偶尔复用”，仍比每次都
new好 - 别依赖“一定复用”，压测时看
GODEBUG=gctrace=1的MB/s和benchstat的B/op是否下降，而不是数New调用次数 - 短生命周期场景（如 HTTP handler）天然适合，因为 goroutine 几乎不跨 P；长任务或频繁
runtime.Gosched()的场景，命中率会明显滑坡 - 如果发现对象复用率持续低于 20%，优先检查是否
Put()太晚（比如 defer）、Get()后忘了Reset()，或对象本身构造成本其实不高（几个 int 字段用 Pool 反而更慢）
什么情况下该自己写对象池，而不是用 sync.Pool
当你需要确定性控制：比如连接池要求阻塞获取、预热固定数量实例、或对象持有外部资源（文件描述符、数据库连接）——sync.Pool 的 GC 清理和生命周期不可控，会让这些需求崩盘。
- 自己实现可用
chan *T + sync.Mutex：例如固定大小的*http.Client池，Get()尝试非阻塞取，失败则新建；Put()仅当缓冲未满才入池 - 禁止用带缓冲的
chan *T直接替代sync.Pool：channel 是全局锁竞争点，高并发下性能瓶颈明显，且无法配合 GC 清理滞留对象 - 若对象很大或需极致性能，考虑
unsafe.Pointer+ 自定义内存页管理，但代价是脱离 GC，必须手动跟踪生命周期 - 数据库连接、
*sql.DB、长连接客户端这类资源，必须用专用连接池（如database/sql内置池），sync.Pool对它们完全不适用
真正难的不是写 sync.Pool，而是判断某个对象是否值得放进去、以及在哪个位置重置哪几个字段。一个 Reset() 漏掉，整条请求链路就可能返回上个用户的敏感数据。
