sync.Pool适用于频繁创建销毁、结构简单、无外部引用且可安全重置的对象；必须设置New字段返回指针，Get后须调用Reset清空状态，避免数据污染和悬垂引用。
享元模式在 Go 里其实不常需要 sync.Pool
Go 的内存模型和 GC 机制让“手动管理对象复用”多数时候得不偿失。真正该用 sync.Pool 的场景，是那些频繁创建销毁、结构简单、无外部引用、可安全重置的对象——比如 bytes.Buffer、fmt.Stringer 实现体、临时切片封装器。不是所有“细粒度对象”都适合享元；盲目套用反而增加 GC 压力或引发数据残留 bug。
sync.Pool 初始化必须设 New 字段
漏掉 New 会导致首次 Get() 返回 nil，后续直接 panic。这不是设计缺陷，而是明确要求你定义“如何构造新实例”。
-
sync.Pool不会自动调用构造函数，也不会推断类型 -
New函数必须返回指针（除非值类型极小且无副作用） - 不要在
New里做耗时操作（如打开文件、网络请求），它可能被并发调用
var bufPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer) // ✅ 正确：返回指针
},
}
对象复用前必须清空状态，否则数据污染
从 sync.Pool.Get() 拿到的对象可能是别人用过的旧实例，字段值未归零。常见错误是直接追加内容而不重置，导致上一次的残留数据混入新结果。
-
bytes.Buffer必须调用Reset()，不能只靠Truncate(0)（后者不释放底层 slice） - 自定义结构体需提供显式
Reset()方法，并在Get()后立即调用 - 避免在
Reset()中释放非内存资源（如关闭文件），sync.Pool不保证回收时机
b := bufPool.Get().(*bytes.Buffer)
b.Reset() // ✅ 关键一步
b.WriteString("hello")
// ... 使用完
bufPool.Put(b)
别把带指针字段或闭包的对象丢进 sync.Pool
如果对象内部持有指向其他内存的指针（比如 map[string]*int 或闭包捕获了局部变量），复用时容易引发悬垂引用或竞态。Go 的 sync.Pool 只负责对象本身生命周期，不管其内部引用关系。
立即学习“go语言免费学习笔记（深入）”；
- 含
map、chan、func类型字段的结构体，大概率不适合池化 - 若必须池化，应在
Reset()中清空 map（for k := range m { delete(m, k) }），而非直接赋nil - 测试时开启
-race，重点观察Put()和Get()之间的共享状态访问
享元真正的难点不在“怎么放进去”，而在“怎么确保拿出来时干净、线程安全、不泄漏上下文”。很多问题要到压测时才暴露，因为复用频率低的时候，脏数据刚好没撞上。
