sync.Pool在微服务中易失效，因其P本地性被goroutine跨P调度破坏，导致Get命中率骤降、shared队列竞争加剧、New频繁触发，复用率暴跌且GC压力不减反增。
sync.Pool 为什么在微服务里容易失效
微服务通常部署在多核机器上，goroutine 调度频繁跨 P（逻辑处理器），而 sync.Pool 的本地缓存只绑定到当前 P。当请求处理 goroutine 在不同 P 间迁移时，Get() 很可能无法命中 private，转而竞争 shared 队列，甚至触发 New 创建新对象——复用率下降，GC 压力不减反增。
常见错误现象：pprof 显示 sync.Pool.Get 调用次数接近 sync.Pool.Put 次数的 2–3 倍；GC 日志中堆增长速率未明显下降。
- 确认是否真有复用：在
New函数里加日志或计数器，观察实际创建频次 - 避免跨 P 迁移：对关键路径（如 HTTP handler）使用
runtime.LockOSThread()绑定 goroutine 到固定 OS 线程（慎用，仅限短生命周期） - 预热池子：服务启动后，用 goroutine 主动调用几次
Get()/Put()，让每个 P 的private至少有一个对象
bytes.Buffer 复用必须重置，否则会累积数据
直接从 sync.Pool 取出的 *bytes.Buffer 可能残留上次使用的内容，不调用 Reset() 就写入，会导致数据错乱或 panic（如 WriteString 后再 Bytes() 返回旧+新内容）。
使用场景：HTTP 请求体解析、JSON 序列化、日志拼接等临时缓冲。
立即学习“go语言免费学习笔记（深入）”；
-
GetBuffer()必须包含buf.Reset()，不能只靠Put时清理 - 不要在
Put前做buf.Truncate(0)——Reset()更安全，它还会清空内部 cap 控制逻辑 - 如果业务需要保留部分 buffer 内容（如流式解析），别用 pool，改用客户端传参模式
json.Decoder/Encoder 复用要重绑定 io.Reader/io.Writer
json.NewDecoder(nil) 创建的对象，首次使用前必须调用 decoder.Reset(r.Body) 或 encoder.Reset(w)，否则会 panic 或读取空数据。
错误信息：panic: reflect.Value.Interface: cannot return value obtained from unexported field or method（常因未重置导致内部状态错乱）
-
Reset()是必须步骤，不是可选优化 - 不要把
decoder放进结构体字段长期持有——它不线程安全，且内部缓存可能污染后续请求 - 若需复用
json.RawMessage解析，建议单独建池，而非复用整个Decoder
Pool 对象大小要控制，避免内存浪费
sync.Pool 不区分对象大小，一个 1MB 的 buffer 和一个 1KB 的 buffer 占用同等“槽位”。如果池中混入大对象，GC 清理后它们仍会长期占据堆空间，直到被新对象覆盖。
性能影响：P99 延迟波动变大，heap profile 显示大量 bytes.makeSlice 分配集中在少数大 buffer 上。
- 在
Put前判断大小：if cap(buf.Bytes()) > 64*1024 { return }，直接丢弃不归还 - 为不同尺寸 buffer 建独立池（如
smallBufferPool/largeBufferPool），避免小对象被大对象挤出 - 注意
bytes.Buffer的 cap 可能远大于 len，用cap(buf.Bytes())判断真实容量，而非len(buf.Bytes())
