根本原因在于GC标记阶段需遍历的对象节点数爆炸式增长，而非堆内存总量大；json.Unmarshal(map[string]interface{})会为每个key、value及嵌套层生成大量短期存活小对象，导致标记器反复扫描“刚死未扫”节点。
GC 扫描对象树压力陡增，根本不是堆总量大，而是短期对象暴增导致标记阶段要遍历的节点数爆炸式增长——gctrace=1里scanned字节数逐轮上涨就是铁证。
为什么 json.Unmarshal(map[string]interface{}) 是高频雷区
每次解析 JSON 到 map[string]interface{}，都会为每个 key、每个 value、每层嵌套生成一堆新堆对象。这些对象生命周期极短（通常只活到 handler 返回），但 GC 还没来得及清扫，下一波请求又来了，标记器被迫反复扫描大量“刚死未扫”的节点。
- 结构体字段含
*sync.Mutex或context.Context会强制整个结构体逃逸，哪怕你只用其中一两个字段 - 闭包捕获大切片或 map，会把整个栈帧拖上堆，比你想象中更容易触发
- 用
fmt.Errorf("xxx: %w", err)在错误路径高频调用，每次新建*fmt.wrapError并复制栈帧，堆上瞬间多出数百个活跃对象
sync.Pool 复用必须重置，否则等于喂 GC 垃圾
sync.Pool 不管理内容，Get 后的对象可能残留任意历史状态。不重置就写入，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函数必须返回全新实例，禁止复用全局变量或带副作用（如打开文件）
GOMEMLIMIT 比 GOGC 更稳，但设错反而放大毛刺
GOGC=100 是比例控制，流量突增时容易堆积垃圾、单次 STW 被拉长；GOMEMLIMIT（Go 1.19+）锚定绝对内存上限，更可控。
- 设为容器内存 limit 的 85%～90%，例如容器 4GB →
GOMEMLIMIT=3600000000 - 禁止运行中反复修改
GOGC：它只影响下一次触发阈值，频繁变更会导致 GC 周期紊乱 - 验证看
debug.ReadGCStats().PauseQuantiles[6]（P99 停顿），不是平均值；配合gctrace=1观察mark termination阶段是否还有尖峰
预分配 + 栈逃逸控制永远比 Pool 优先
复用是补救，不分配才是根本。Go 编译器靠逃逸分析决定分配位置，go build -gcflags="-m -l" 是必跑命令。
- 用
make([]byte, 0, 1024)替代make([]byte, 1024)：前者不初始化零值，少算 1024 字节活跃对象 - HTTP body 读取别用
bytes.Buffer.String()再strings.Split()，改用bufio.Scanner或预分配[]byte+bytes.Split() - JSON 解析优先用结构体 +
json.RawMessage延迟解析，或用easyjson生成零拷贝代码 - 高频小对象（token、log context）才适合
sync.Pool；大对象或复用率低的对象用了反而拖慢 GC
最易被忽略的是：GC 压力不在对象大小，而在对象图深度和连接关系。一个含 10 个指针字段的结构体，哪怕只有 100 字节，也可能让标记器多走几百个节点——逃逸分析报告里那句 escapes to heap，往往比内存占用数字更危险。
