直接new()导致GC压力大，因json.Unmarshal每次分配新[]byte和嵌套结构体，高并发下短生命周期对象激增；应复用*bytes.Buffer、预分配[]byte或json.RawMessage缓冲，用sync.Pool池化底层数组而非RawMessage本身。
为什么直接 new() 会导致 GC 压力大
Go 的 json.Unmarshal 默认每次调用都分配新的 []byte 和嵌套结构体（如 map[string]interface{} 或自定义 struct 字段），尤其在高并发解析场景下，短生命周期对象密集生成，会显著抬高 GC 频率。这不是 JSON 库的问题，而是 Go 内存模型的自然结果——你没复用，运行时就只能帮你 new。
常见现象：runtime.MemStats.NextGC 持续偏低、GCCPUFraction 异常升高、pprof 显示大量 runtime.mallocgc 调用栈集中在 encoding/json 路径。
- 避免对单次请求“省一个 alloc”而忽略整体吞吐：小对象池化收益有限，重点应放在高频复用的中间载体上（如
*bytes.Buffer、预分配的[][]byte、或整个json.RawMessage缓冲） - sync.Pool 不是全局缓存：它按 P（逻辑处理器）本地存储，Get 可能返回 nil，Put 也不保证立即回收——别把它当
map用 - 池中对象必须可安全复用：比如不能含未清零的指针字段、goroutine 局部状态或闭包引用
怎样为 json.RawMessage 设计安全的 Pool
json.RawMessage 是字节切片的包装，本身不分配堆内存，但底层 []byte 往往来自 make([]byte, 0, N)。直接池化 json.RawMessage 没意义，真正要池化的是其底层数组缓冲。
实操建议：
- 定义池时 New 函数返回
*[]byte（注意是指针），而非json.RawMessage；这样 Put 时可重置长度为 0，保留容量 - Get 后必须检查是否为 nil，再调用
buf = append(*buf[:0], src...)复制数据，而非直接赋值 - 别在池中放带 finalizer 的对象（如含
io.ReadCloser的结构），Pool 不触发 finalizer
示例关键片段：
var rawBufPool = sync.Pool{
New: func() interface{} {
b := make([]byte, 0, 4096)
return &b
},
}
// 使用时：
bufPtr := rawBufPool.Get().(*[]byte)
*bufPtr = append((*bufPtr)[:0], data...)
var raw json.RawMessage = (*bufPtr)[:]
err := json.Unmarshal(raw, &target)
rawBufPool.Put(bufPtr) // 注意：Put 的是 *[]byte，不是 raw
struct 解析时复用目标实例比复用缓冲更有效
比起池化字节缓冲，复用已分配的 struct 实例往往带来更稳定收益——因为 struct 字段多为小整数、字符串头或指针，GC 压力主要来自其内部字段（如 string 底层数组、slice 数据）的重复分配。
实操要点：
- 为每个常用解析目标类型单独建池，New 返回
&MyStruct{}，Get 后用Reset()方法清空字段（需手动实现，例如将 slice 置为nil、string 置为""） - 避免池化含
sync.Mutex或sync.Once的 struct：这些类型不可拷贝，复用前必须确保已解锁/未执行 - 如果 struct 含指针字段指向外部资源（如数据库连接），池化前务必解绑，否则造成资源泄漏
错误示范：pool.Put(&MyStruct{Conn: dbConn}) —— Conn 不会被自动关闭，下次 Get 到的对象可能持有已失效连接。
sync.Pool 在 HTTP handler 中的典型误用
很多人在 http.HandlerFunc 里直接 Get/Put，却忽略两个事实：1）handler 可能被同一 goroutine 多次复用（如 fasthttp）；2）net/http 的 handler 每次请求新建 goroutine，但 Pool 对象可能跨请求残留。
风险点：
- Put 过早：在 handler 返回前就 Put，但后续代码（如日志、metric 上报）还访问该对象，导致 panic 或脏数据
- Put 过晚：defer Put 导致对象在 handler 退出后才入池，若此时 P 发生迁移，对象可能滞留在旧 P 的本地池中，长期不被复用
- 混用不同用途的缓冲：用同一个 Pool 存 1KB 和 1MB 的 buffer，小缓冲总被大缓冲挤出，失去局部性
稳妥做法：在 handler 开头 Get，在所有业务逻辑结束、响应写出后（且确认无后续引用）再 Put；必要时加注释说明生命周期边界。
最易被忽略的一点：sync.Pool 的对象没有确定的销毁时机，也不会调用 Free 方法。如果你依赖某次 Put 后资源立即释放（比如文件描述符、内存映射区），必须自己管理，别指望 Pool。
