根本问题在于json.unmarshal(map[string]interface{})引发对象图爆炸式膨胀，每个key、value及嵌套层均生成独立堆对象，导致gc标记阶段反复扫描“刚死未扫”节点，gctrace=1中scanned字节数逐轮上涨即为铁证。
根本问题不在包大小，而在反序列化方式触发了对象图爆炸式膨胀——json.Unmarshal 到 map[string]interface{} 会让每个 key、value、嵌套层级都生成独立堆对象，GC 标记阶段被迫反复扫描“刚死未扫”的节点，gctrace=1 中 scanned 字节数逐轮上涨就是直接证据。
别用 map[string]interface{} 解析大 JSON 包
这是高并发服务里最典型的 GC 雷区。哪怕只解析一个 2MB 的 JSON，用 map[string]interface{} 也可能生成数万个短期存活小对象，全部堆分配、全进标记队列。
- 结构体字段含
*sync.Mutex或context.Context会强制整个结构体逃逸，哪怕你只读其中一两个字段 - 闭包捕获大切片或 map，会把整帧栈拖上堆，比你预估的更容易发生
- 用
fmt.Errorf("xxx: %w", err)在错误路径高频调用，每次新建*fmt.wrapError并复制栈帧，堆上瞬间多出数百个活跃对象
改用结构体 + json.RawMessage 延迟解析
把真正需要立刻处理的字段定义为结构体字段，不确定/不常读的字段用 json.RawMessage 暂存字节流，等用到时再局部解析——这样能砍掉 70%+ 的短期堆对象。
-
json.RawMessage是[]byte别名，零拷贝，不触发任何新分配 - 嵌套数组或对象字段可先
Unmarshal到json.RawMessage，后续按需解析子结构 - 如果字段类型动态，可用
json.Unmarshal(raw, &v)单独解析，避免污染主对象图
sync.Pool 复用必须重置，否则等于喂 GC 垃圾
很多人以为从池里取出来就能直接写，其实 sync.Pool 完全不管理内容。比如复用 *bytes.Buffer，不调 b.Reset() 就写入，上次残留数据还在底层数组里，GC 会认为那块内存仍被引用，无法回收对应数组。
-
*bytes.Buffer必须调b.Reset()，不能只清空b.Len() - 切片复用后要
slice = slice[:0]，不是slice = nil（后者丢掉底层数组） - map 复用需先
clear(m)（Go 1.21+）或m = nil; m = make(map[string]int） - 自定义结构体的
New函数必须返回全新实例，禁止复用全局变量或带副作用（如打开文件）
验证是否真优化到位，别信平均值
优化后看 debug.ReadGCStats().PauseQuantiles[6]（P99 停顿），不是平均停顿；配合 GODEBUG=gctrace=1 观察 mark termination 阶段是否还有尖峰。如果 scanned 字节数不再逐轮上涨，说明对象图膨胀被控住了。
最常被忽略的是：预分配和逃逸控制永远比 sync.Pool 优先。用 go build -gcflags="-m -l" 看关键路径有没有 escapes to heap，有就重构——让对象别上堆，才是根治办法。
