sync.pool 不适合复用大于32kb的结构体，因其绕过mcache直入mheap，增加gc扫描开销、推高heapalloc并延长stw；应拆解结构体，仅池化轻量“壳”，数据改用栈分配或预分配切片。
别用 sync.pool 复用大结构体——它大概率不会降低 gc 频率，反而让 heapalloc 持续上涨、stw 变长。
为什么 >32KB 的结构体放进 sync.Pool 会加重 GC 压力
Go 运行时对对象分配有明确分界：≤32KB 走 mcache（线程本地缓存），可被高效复用；>32KB 直接走 mheap，成为 GC 必须扫描的堆对象。而 sync.Pool.Put() 进去的大结构体，只要含指针字段（比如 data []byte、meta map[string]interface{}），GC 就得递归追踪所有子对象，扫描开销剧增。
- 典型现象：
runtime.ReadMemStats显示Mallocs下降了，但HeapAlloc持续攀升、NextGC提前触发 - Go 1.19+ 更激进：闲置 P 的本地池会被提前清空，Put 100 次，实际 Get 到旧实例可能不到 5 次
- Pool 不控制生命周期，这些大块内存可能长期滞留，直到下一次 GC 才批量清理
sync.Pool.New 返回大对象是致命陷阱
New 函数不是初始化钩子，而是兜底工厂；但它若每次返回一个 >32KB 的新结构体，等于主动把压力引向 mheap。
- 错误写法：
New: func() interface{} { return &BigStruct{data: make([]byte, 0, 1024*1024)} }→ 每次调用New都预占 1MB 堆内存，且无法被 mcache 缓存 - 更糟的是：这个
[]byte底层数组一旦逃逸，就变成 GC 标记对象，还拖慢 STW - 正确思路：把大结构体拆解，只池化真正高频变动的“壳”，数据部分改用栈分配或预分配切片复用
哪些“看起来大”其实根本不该池化
很多你以为的“大结构体”，编译器早已优化为栈分配或零成本复制，强行池化纯属干扰运行时。
-
string、time.Time、net.IP、error这类值类型复制极快，且不触发堆分配 - 小 struct（如
struct{a, b int}）分配成本远低于sync.Pool的原子操作和哈希查找 - 接口值（如
io.Reader）本身只是 2 字段，复用重点应在具体实现（如*bytes.Buffer），而非接口变量
真正该复用的，是短命、无外部依赖的中型内存对象
sync.Pool 合适的场景很窄：高频分配 + 快速丢弃 + 无外部依赖的纯内存对象。
- 推荐用法：
make([]byte, 0, N)配合append()复用底层数组，比塞进 Pool 更轻量 - 典型有效场景：HTTP handler 中的
bytes.Buffer、json.Decoder、http.Header实例 - 关键动作必须四步闭环：
Get→ 用 →Reset（如buf.Reset()）→Put；漏掉Reset就等于放脏数据进池，下次 Get 到就是 bug 温床
最易被忽略的一点：压测时别只看代码写了 sync.Pool，得盯 runtime.ReadMemStats 的 PauseNs 和 NumGC —— GC 停顿没降，说明优化没生效，甚至反向拖累。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
