sync.Pool.Get()返回的对象不能直接用，因其可能残留旧数据（如bytes.Buffer的Buf字段或http.Header中的过期键值），必须显式调用Reset()或手动清空关键字段，否则会导致逻辑错误、数据污染或敏感信息泄露。
sync.Pool 不是万能缓存，它只适合短生命周期、高频率创建的临时对象复用；用错场景反而增加 GC 压力或引发数据污染。
为什么 sync.Pool.Get() 返回的对象不能直接用
Pool 中的对象可能来自上一次使用后未清理的状态，比如 bytes.Buffer 的 Buf 字段可能还残留旧数据，http.Request 的 Header 可能包含过期键值。不重置就用，轻则逻辑错误（如 header 覆盖），重则泄露敏感信息。
- 必须在
Get()后显式调用Reset()或手动清空关键字段（如buf.Reset()、req.Header = make(http.Header)） -
New函数里不做初始化逻辑——它只负责构造“干净”的新对象，状态重置必须由使用者控制 - 结构体指针从 Pool 取出后，字段如
pos int、len、cap都需重置，否则行为不可预测
sync.Pool.New 函数的常见误写方式
写错 New 会导致对象池失效或内存浪费。典型错误包括闭包捕获大变量、预分配过大底层数组、返回已初始化的 map/slice。
- ❌
return &bytes.Buffer{Buf: make([]byte, 0, 4096)}—— 每次New都分配 4KB，但多数请求只用几百字节，浪费明显 - ❌
return &MyStruct{data: bigData}（bigData是闭包捕获的全局大对象）—— 导致对象无法被 GC，长期驻留堆中 - ✅ 正确做法：只做最轻量构造，例如
return new(bytes.Buffer)或return &Buffer{data: make([]byte, 0, 1024)}
如何验证 sync.Pool 是否真正起效
别只看代码写了 Get/Put 就以为生效了。Pool 是否命中、是否减少分配，得靠运行时指标说话。
- 对比压测前后
go tool trace中 “Heap allocated” 曲线斜率：下降越陡，说明分配越少 - 用
runtime.ReadMemStats抓取Allocs/op和PauseNs，重点看 GC pause 总时长是否缩短 - 手动埋点统计命中率：用
atomic.Int64在New和Get处分别计数，命中率 = (Get 总数 − New 总数) / Get 总数 - 注意逃逸分析：
go build -gcflags="-m"确认对象没逃逸到堆——若逃逸，Pool 完全无效
Pool 的核心约束在于“临时性”：它不保证对象存活，不提供容量控制，也不支持跨 goroutine 长期持有。一旦对象生命周期变长、复用模式不稳定，或者需要精确内存控制（比如定长网络包缓冲区），就得切到 chan [128]byte 或 ring buffer 这类更底层的手动管理方案。
