sync.Pool复用大结构体反而加重GC压力：因超32KB对象绕过mcache直入mheap，成为GC必扫堆对象，且含指针字段加剧扫描开销，导致HeapAlloc上涨、STW延长。
别用 sync.Pool 复用大结构体——它大概率不会降低 GC 频率，反而让 HeapAlloc 持续上涨、STW 变长。
为什么大结构体放进 sync.Pool 反而加重 GC 压力
Go 的 sync.Pool 本地池（per-P）底层依赖 mcache 分配，而大于 32KB 的对象会绕过 mcache 直接走 mheap；一旦进 mheap，就变成 GC 必须扫描的堆对象，且 Pool 不控制生命周期，这些大块内存可能长期滞留，直到下一次 GC 才批量清理。
- 典型翻车现象：
runtime.ReadMemStats显示Mallocs下降了，但HeapAlloc持续攀升、NextGC提前触发 - 根本原因：Put 进去的大结构体含指针字段（比如
[]byte、map[string]*T），GC 必须追踪其所有子对象，扫描开销剧增 - Go 1.19+ 更激进：闲置 P 的本地池会被提前清空，导致复用率骤降，你 Put 了 100 次，实际 Get 到旧实例可能不到 5 次
sync.Pool.New 返回大对象时的致命陷阱
New 函数不是初始化钩子，而是兜底工厂；但它若每次返回一个 >32KB 的新结构体，等于主动把压力引向 mheap —— 尤其当这个结构体内部还持有 make([]byte, 1 这类底层数组时，相当于每调用一次 <code>New 就分配 1MB 堆内存。
- 错误写法：
New: func() interface{} { return &BigStruct{data: make([]byte, 0, 1024*1024)} }→ 每次 New 都预占 1MB，且无法被 mcache 缓存 - 正确思路：把大结构体拆解，只池化真正高频变动的“壳”，数据部分改用栈分配或预分配切片复用
- 替代方案：对固定大小的大缓冲，直接用
make([]byte, 0, N)+buf = buf[:0]复用底层数组，比塞进 Pool 更轻量
哪些“看起来大”其实不该池化的类型
很多你以为的“大结构体”，编译器早已优化为栈分配或零成本复制，强行池化纯属干扰运行时。
立即学习“go语言免费学习笔记（深入）”；
-
string、error（如fmt.Errorf）、time.Time、net.IP：底层是小结构体（≤2 字段），值传递无压力，池化毫无意义 - 含
unsafe.Pointer或外部资源句柄的结构体（如封装了*os.File或未关闭的net.Conn）：Pool 不做 Close，Put 后资源泄漏，下次 Get 还可能 panic - 已自带复用机制的对象：比如
http.Request在标准库中已被复用，再套一层 Pool 只会引入状态污染风险
真要复用“大”中间对象，该怎么做
所谓“大”，得先确认它是否真的逃逸到堆上。用 go build -gcflags="-m -l" 看清楚：如果结构体本身没逃逸，压根不用 Pool；如果逃逸了，优先考虑预分配 + 截断，而非 Pool。
- 对含大 slice 字段的结构体：在
New中用make([]byte, 0, N)预分配底层数组，Get 后用s = s[:0]重置长度，不 new 新数组 - 避免嵌套指针：结构体里别放
*[]byte或*map[string]interface{}，这会让 GC 扫描链路变长；改用值类型字段 + Reset 方法清空 - 监控关键指标：关注
pprof heap --alloc_space中该类型是否高频出现在 top allocators；如果不是，加 Pool 就是白忙
真正难的不是“怎么放进去”，而是判断“有没有必要放”。大结构体一旦进 Pool，它的生命周期就脱离你的掌控——你没法知道它何时被谁取走、是否已被 GC 标记、底层数组是否还在被其他 goroutine 引用。这种不确定性，在高并发服务里比多几次 malloc 更危险。
