sync.Pool.New必须每次返回新实例，禁止复用全局变量；Get后须立即幂等Reset；Put前需清理指针字段防内存泄漏；命中率低源于P分片设计，非配置问题。
sync.Pool.New 必须返回新实例，不能复用全局变量
很多人写 New 时直接返回一个包级变量地址，比如 return &globalBuf，这会导致所有 goroutine 共享同一块内存，引发竞态和脏数据。Go 不做线程安全封装，sync.Pool 也不负责隔离——它只管“放进去、拿出来”，不保证“拿出来的是谁的”。New 的唯一职责是：每次调用都返回一个干净、未被使用的实例。
- ✅ 正确写法：
func() interface{} { return &MyStruct{} }或return bytes.NewBuffer(nil) - ❌ 错误写法：
var onceBuf = &bytes.Buffer{}+return onceBuf - 副作用风险：如果
New里打开文件、启动 goroutine 或写日志，这些操作会在 GC 清理池时意外触发多次
Get 后必须立即 Reset，且 Reset 要幂等
sync.Pool.Get() 返回的对象可能来自上一次 Put，字段值全在，也可能为 nil（池空且没设 New）。Go 从不帮你清零，也不会兜底初始化。你拿到的不是“新对象”，而是“上次用完没擦干净的旧对象”。
- 对
*bytes.Buffer：必须调buf.Reset()，不能只靠buf.Truncate(0)（后者不归零cap） - 对自定义结构体：Reset 方法要覆盖所有可变字段，包括
id int、ts time.Time、err error等标量；切片字段用s = s[:0]截断长度，别s = nil（否则丢掉底层数组） - map 字段不能留着不处理：必须遍历
delete(m, k)或用for range清空，否则 map 底层 bucket 一直被引用，GC 不回收
Put 前必须清理指针字段，否则 RSS 持续上涨
结构体里有 data []byte、cache map[string]int 或 ch chan int？直接 Put() 就等于把指针“钉死”在池里。GC 看到这些字段还活着，就不会释放它们指向的内存，最终进程 RSS 暴涨，但 heap profile 可能看不出明显泄漏。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 切片字段：用
s = s[:0]，保留底层数组以供复用 - map 字段：用
for k := range m { delete(m, k) }，避免新建 map（破坏复用价值） - channel 字段：必须先
close(ch)再置为nil，否则下次 Get 到的 channel 仍可读写，行为不可预测 - 嵌套结构体字段：Reset 要递归调用，别漏掉
.child.field
命中率低不是代码问题，是运行时按 P 分片导致的
高并发下 sync.Pool 命中率骤降，常被误判为“池没配好”或“对象太大”。真实原因是 Go 运行时设计：每个逻辑处理器（P）维护独立本地缓存，对象 Put() 后大概率留在当前 goroutine 所在的 P 里；一旦 goroutine 被调度到别的 P（比如网络 I/O 阻塞后唤醒），就拿不到之前放进去的对象。
立即学习“go语言免费学习笔记（深入）”；
- 这不是 bug，是权衡：牺牲跨 P 可见性，换取无锁快速存取
- 无法通过“加大池子”解决，反而可能因 GC 清理更频繁而降低收益
- 若业务强依赖跨 goroutine 复用（如 worker 池固定一批对象），该自己用
chan *T实现有界池，而非依赖sync.Pool
最易被忽略的一点：sync.Pool 不是“缓存”，也不是“对象生命周期管理器”。它不保证对象一定被复用，也不承诺 Put 后还能 Get 到。它的价值仅在于“减少高频分配”，前提是你的对象足够小、生命周期足够短、Reset 足够彻底——三者缺一，优化就变成负优化。
