sync.pool.new 仅在池空时创建新对象，不参与重置；对象复用前必须手动清零，gc 不会重置字段或调用清理逻辑，put 前未重置易致脏数据或内存泄漏。
sync.Pool.New 与对象重置没有关系
sync.Pool 的 New 字段只在池中无可用对象时被调用，用来创建新对象；它不会在 GC 时自动触发，也不参与对象“重置”。很多人误以为 New 是清理回调，其实它只是兜底工厂函数——GC 不会调用它，Pool 本身也不会在对象被取走前自动清空字段。
真正影响重置行为的，是使用者是否在 Get 后手动归还（Put）前清空状态。Go 运行时只保证：归还的对象可能在下次 Get 时被复用，但不保证其字段值为零值。
-
Get返回的对象可能是之前用过的，字段残留旧数据 -
Put不会自动调用任何清理逻辑，只是把指针放回池中 - 如果类型包含指针、切片或 map，未清理就
Put可能导致内存泄漏或脏数据复用
为什么不能依赖 GC 来重置 sync.Pool 中的对象
Go 的垃圾回收器不会感知 sync.Pool 的生命周期，更不会在对象被回收前执行用户定义的“重置”逻辑。Pool 中的对象只要被 Put 进去，就可能被后续 Get 直接返回——哪怕它刚被 GC 扫描过（实际上，只要池持有引用，它就不会被 GC 回收）。
关键点在于：sync.Pool 本身持有对象的强引用，这些对象在 GC 周期中会被标记为存活。只有当整个 Pool 实例不可达，且其中所有对象也无其他引用时，它们才可能被回收——但这和“重置”完全无关。
- GC 不会调用任何析构函数（Go 没有析构函数）
- Pool 中对象的字段值在
Get时保持原样，除非你显式赋值或清零 - 依赖 GC 清理字段 = 等同于读取未初始化内存，行为不可控
安全重用 sync.Pool 对象的实操方式
正确做法是在每次 Put 前手动重置对象状态，或者在 Get 后立即初始化。推荐在 Get 返回后做初始化，因为这样能确保每次拿到的对象都处于已知干净状态，避免遗漏 Put 路径。
var bufPool = &sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
// 正确：Get 后重置，不依赖 Put 是否被调用
buf := bufPool.Get().(*bytes.Buffer)
buf.Reset() // 必须显式调用
// ... use buf
bufPool.Put(buf)
- 对结构体，可提供
Reset()方法并统一调用 - 避免在
New中分配大对象（如预分配大 slice），应延迟到Reset()中按需扩容 - 如果对象含指针字段（如
*http.Request），必须置为nil，否则可能阻止下游对象被 GC
sync.Pool 在 Go 1.22+ 的变化与注意事项
Go 1.22 引入了 sync.Pool 的“批处理释放”优化：运行时会在每轮 GC 后批量释放部分闲置对象，降低内存驻留量。但这仍不改变“不自动重置”的本质——它只是让池更激进地丢弃未使用的对象，而不是更温柔地清理它们。
- 池中对象可能比以前更早被丢弃，但
Get返回的对象依然可能来自上一轮 GC 前的缓存 - 不要假设某次
Put后对象一定会活过下一次 GC - 测试时建议禁用 GC（
GOGC=off）或使用runtime.GC()强制触发，验证重置逻辑是否真正在各种生命周期下生效
Put 路径的 panic 分支、提前 return 或 defer 中的 Put 遗漏——它们会让脏对象滞留在业务逻辑外，下次被意外复用。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
