sync.pool是解决高并发内存压力的生产级设施，必须手动reset获取对象、严格控制put时机、new函数仅作兜底且禁止副作用，适用于短生命周期可重置对象，用错比不用更危险。
sync.Pool 不是用来“学 Go 语法”的工具，它是解决真实高并发内存压力的生产级设施；用错比不用更危险——尤其在 HTTP handler、JSON 解析、buffer 复用等高频场景里。
sync.Pool.Get 返回的对象必须手动 Reset
Get 拿到的不是新对象，而是上次用过的“脏”实例。bytes.Buffer 的 buf.Bytes() 可能还带着上个请求的响应体，[]byte 切片的 len 可能非零，map 字段可能存着旧 key。
-
bytes.Buffer必须调buf.Reset()，不能只赋值nil -
[]byte必须重置长度：buf = buf[:0]，不是buf = nil - 自定义结构体含
map字段时，Put 前得mapclear(m)或设为nil再make - 含指针字段（如
*sync.Mutex）必须确保已解锁，否则下次 Get 会 panic
sync.Pool.Put 的时机比你想的更敏感
Put 是把对象交出去，不是“打个包寄存”，它可能下一毫秒就被别的 goroutine 拿走。一旦 Put，原 goroutine 就不能再碰这个对象。
- 禁止在
defer里无条件pool.Put(x)：如果 x 被传给 goroutine、写入 channel、或闭包捕获，就是典型的 use-after-free - HTTP handler 中，Put 必须在所有逻辑结束之后，不能放在函数开头或中间 defer 里
- 用于
io.Copy(dst, src)的 writer，Put 必须等io.Copy返回后手动调用 - 对象若被作为返回值传出，绝对不能 Put
New 函数不是初始化钩子，而是兜底工厂
New 只在池空时触发，且不保证每次 Get 都调用。它唯一职责是：返回一个干净、全新、无副作用的对象。
- 不能返回全局变量：
return &globalBuf→ 多 goroutine 并发读写同一内存 - 不能做耗时操作：
os.Open、http.Get等会卡住整个 Get 路径 - 预分配容量必须在 New 里完成，例如
make([]byte, 0, 64*1024)，否则复用失去意义 - 结构体字段要显式初始化：
&MyStruct{Data: make([]byte, 0, 128)}，不能靠字段默认零值撑场
高并发下性能反而下降？检查 P 迁移和池碎片
sync.Pool 按 P 分片，每个 P 有 private 缓存。但 goroutine 频繁跨 P 调度（比如大量 channel 阻塞/唤醒），会导致本地池命中率暴跌，退化成锁竞争。
- 观察
runtime.ReadMemStats().Mallocs - Frees：长期不收敛说明池在囤积对象，没被 GC 及时清掉 - 大缓冲（>32KB）慎用：可能绕过 mcache 直接走 mheap，抬高 GC 成本
- 切片类对象 Put 前检查容量：
if cap(buf) > 64*1024 { /* 丢弃不 Put */ }，防碎片堆积 - pprof 对比
allocs/op和 STW 时间：没降反升，说明 Pool 引入了新瓶颈
最易被忽略的点：sync.Pool 不是缓存，也不是连接池；它只接受“用完即弃、状态可重置、生命周期短于一次请求”的对象。拿不准就别放——宁可多一次 new，也不要一次脏数据穿透整个服务链路。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
