get返回nil是正常设计，需先判空再初始化并手动reset；new仅兜底调用且须返回干净新实例；put前必须清空字段，否则复用脏对象引发错乱。
sync.Pool.Get 返回 nil 怎么办
Go 的 sync.Pool.Get 不保证返回非 nil 值，它可能返回刚被 GC 回收的对象、空指针，甚至上一次 Put 进去但已被清理的残留值。这不是 bug，是设计使然——Pool 本身不持有强引用，GC 可随时清理其中对象。
所以每次调用 Get 后必须做非空判断和初始化：
obj := pool.Get().(*MyStruct)
if obj == nil {
obj = &MyStruct{} // 或调用构造函数
}
// 注意：此时 obj 可能是旧对象，字段未清零，需手动重置
obj.Reset() // 必须提供 Reset 方法或显式赋值
- 不要依赖
Get返回“干净”对象，Pool 不负责清零字段 - 避免在
Reset中分配新内存（比如重新 make 切片），否则抵消 Pool 的收益 - 如果结构体含指针或 map/slice 字段，
Reset必须显式置为 nil 或重置长度容量
sync.Pool.New 字段到底该不该设
sync.Pool 的 New 字段是可选的，但它不是“备选构造器”，而是兜底机制：仅当 Get 返回 nil 时才调用。它不参与对象复用逻辑，也不影响已有对象的生命周期。
推荐始终设置 New，但注意两点：
- 函数体必须返回新分配的对象（不能返回局部变量地址，也不能返回已存在的全局对象）
- 函数内不要做耗时操作（如打开文件、网络请求），Pool 是为高频短生命周期对象设计的
- 若对象构造成本高（比如含大 buffer），New 里直接
make([]byte, 0, 1024)比让使用者每次自己 make 更高效
示例：
var bufPool = &sync.Pool{
New: func() interface{} {
return &bytes.Buffer{} // ✅ 正确：每次 new 一个新实例
},
}
Put 前要不要清空字段
必须清空。Go 不会在 Put 前自动重置对象，任何残留数据都会带到下一次 Get 使用中，极易引发隐蔽 bug（比如前一次的 slice 数据还在，append 后内容错乱）。
清空不是“可选优化”，是使用 sync.Pool 的硬性前提：
- 基础类型字段（int/bool/string）直接赋零值：
obj.count = 0 - slice/map/chan 要置为 nil 或用
obj.items = obj.items[:0]（保留底层数组但清空长度） - 指针字段（如
*http.Request）必须置为 nil，否则 GC 无法回收被引用的对象 - 避免在 Put 前调用
Reset()外的其他方法，尤其不要 defer 清理（defer 在函数退出才执行，Put 已提前发生）
为什么对象池不适合存储带状态的连接或句柄
sync.Pool 的对象可能被任意 goroutine 获取，且无顺序、无所有权保证。如果把 *sql.Conn 或 net.Conn 放进去，会出现：
- 连接被 A goroutine Put 后，B goroutine Get 到，但连接已在 A 中关闭或超时
- 连接内部缓冲区残留未读数据，导致协议解析失败
- 连接绑定了 TLS session 或自定义 deadline，复用后行为不可控
这类资源应交给专用连接池（如 database/sql.DB 内置池、http.Transport）管理，它们有状态检查、健康探测、超时驱逐等机制。sync.Pool 只适合无状态、可随意丢弃、构造/销毁开销大的临时对象，比如 []byte 缓冲、JSON 解析器、正则匹配器。
真正容易被忽略的是：即使你确保每次 Put 前 close 了连接，Pool 仍可能在 GC 期间把已 close 的连接交给别人——因为 close 不等于立即释放底层 fd，而 Pool 对象的生命周期完全独立于你的业务逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
