sync.pool.get()返回nil是正常设计，需先判空再初始化并手动reset；new仅兜底调用且须返回干净新实例；put前必须清空字段，否则复用脏对象引发错乱。
sync.Pool.Get() 返回 nil 怎么办
它本来就可能返回 nil，不是 bug，是设计如此。官方文档明确说：Get() 不保证返回非空对象，尤其在池刚初始化或 GC 后清空时。
- 必须做空值判断：比如
buf := bufPool.Get().(*bytes.Buffer)前加if buf == nil { buf = new(bytes.Buffer) } - 别依赖
New函数兜底——它只在池空时调用，且不保证每次Get都触发；New里也不能有副作用（如打开文件、发 HTTP） - 常见错误是直接类型断言后就用，panic 报
invalid memory address或panic: interface conversion
为什么 Put 前不 Reset 就会复用脏数据
sync.Pool 完全不关心对象状态，它只管存和取。所谓“复用”，就是把上一个 goroutine 用完的内存块原样交给你，字段一个字节都不清。
-
*bytes.Buffer必须调buf.Reset()：它清长度、保留底层数组，这才是复用意义所在 - 自定义结构体要手动重置所有可变字段：
s.Slice = s.Slice[:0]、s.Map = nil（再make）、s.Counter = 0 - 含指针字段时更危险：如果
s.Cache是*map[string]int，Reset 里漏掉*s.Cache = map[string]int{}，下次 Get 到的就是残留旧数据的 map
高并发下 Get/put 反而比 new 慢的根源
根本不是 Pool 本身慢，而是 goroutine 跨 P 迁移导致本地池命中率暴跌，被迫退化成锁竞争。
- 典型诱因：
runtime.Gosched()、channel 阻塞后唤醒到不同 P、大量select+ timeout - 现象：pprof 看到
sync.Pool.Get和sync.Pool.Put占 CPU 高，但对象分配频次没降 - 验证方法：开
GODEBUG=schedtrace=1000观察 P 切换频率；或用runtime.NumGoroutine()+runtime.ReadMemStats()对比压测前后Mallocs - Frees差值
大对象或含长生命周期引用时为何内存不降反升
Pool 不是缓存，是“临时对象暂存点”。它不跟踪引用关系，Put 进去的对象只要被其他 goroutine 持有，GC 就无法回收，反而让内存滞留更久。
- 对象大小 >32KB 会绕过 mcache 直接走 mheap，GC 扫描成本飙升
- 结构体字段含指向长期存活对象的指针（如全局配置、DB 连接），Put 后该指针仍被持有，整个对象链路无法释放
- Pool 无容量限制，波峰过后闲置对象等下次 GC 才清空——监控
runtime.MemStats.HeapAlloc是否持续上涨，而非只看HeapInuse
实际用起来，最难的不是写对 Get 和 Put，而是判断这个对象到底适不适合进 Pool：它得短命、干净、结构稳定，且不能被任何外部作用域悄悄抓住尾巴。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
