Go JSON 解析怎么减少内存分配：Decoder、RawMessage 与基准测试边界

订单事件接口QPS从几百涨到几千后，内存曲线往往比CPU先出压力预警：同一份JSON如果先整体读入再json.Unmarshal，请求体、临时字节切片和完整结构体很可能在同一个GC采样周期里同时驻留内存。Go标准库没有“万能最快”的JSON解析方案，真正要权衡的是数据体积、字段使用率、流式处理边界和内存分配次数。

小JSON、字段几乎全用到时，json.Unmarshal 足够直接高效；请求体较大或者需要按数组逐条处理时优先用 json.Decoder；只有少数字段需要二次解析的场景，才用 json.RawMessage 延后冷数据的解析动作。

基线先固定：同一份订单事件跑三条路径

别急着把所有解码代码全换成Decoder。性能对比最忌讳输入样本不一致：字段数量、数组长度、是否包含冷字段都会直接影响最终测试结果。我们先准备一批固定结构的订单事件，每条记录包含常用的订单号、金额字段，以及一个只有少数业务才会读取的扩展对象。

type OrderEvent struct {
    ID     string          `json:"id"`
    Amount int64           `json:"amount"`
    UserID int64           `json:"user_id"`
    Extra  json.RawMessage `json:"extra"`
}

func decodeWhole(data []byte) ([]OrderEvent, error) {
    var events []OrderEvent
    err := json.Unmarshal(data, &events)
    return events, err
}

func decodeStream(data []byte) ([]OrderEvent, error) {
    dec := json.NewDecoder(bytes.NewReader(data))
    var events []OrderEvent
    if err := dec.Decode(&events); err != nil {
        return nil, err
    }
    return events, nil
}

这段代码的初始版本刻意保持对比公平：两种解码方式最后都返回完整切片，可以验证“用Decoder就能自动降低内存分配”这个常见误解，但没法体现Decoder最擅长的边读边处理特性。基线记录的是参考值，不是跨机器通用的绝对性能结论。

基准结果看三件事：吞吐、分配次数和峰值占用

在同一个包内编写基准测试，避免把生成测试数据的成本混进解析耗时里。b.ReportAllocs 会把每轮的内存分配数据直接输出到结果里，b.SetBytes 则方便统计每秒能处理的数据量。

func BenchmarkDecodeWhole(b *testing.B) {
    b.ReportAllocs()
    b.SetBytes(int64(len(payload)))
    for i := 0; i 

本地跑测试时重点看三列数值：ns/op 反映单轮操作耗时，B/op 反映单轮分配的总字节数，allocs/op 反映单轮的堆内存分配次数。如果两条测试路径最终都构造出完整结果切片，Decoder很可能不会带来明显性能优势，甚至会因为Reader状态维护产生小幅额外开销；这不代表Decoder没用，只是测试场景还没进入流式处理的收益区间。

数组很大时，Decoder 的价值在于边读边处理

把整个数组一次性解码成 []OrderEvent 之后再处理，内存峰值会跟着数组长度同步上涨。订单归档、批量校验这类场景通常只需要逐条把数据写入队列或数据库，完全可以先读取数组的边界标记，再每次解码单条对象处理。

func consumeEvents(data []byte, handle func(OrderEvent) error) error {
    dec := json.NewDecoder(bytes.NewReader(data))
    token, err := dec.Token()
    if err != nil || token != json.Delim('[') {
        return fmt.Errorf("events must be a JSON array")
    }
    for dec.More() {
        var event OrderEvent
        if err := dec.Decode(&event); err != nil {
            return err
        }
        if err := handle(event); err != nil {
            return err
        }
    }
    _, err = dec.Token()
    return err
}

这种模式下内存占用不需要同时容纳整个结果切片，但单条事件如果本身体积很大，字段校验和下游写入也可能成为新的性能瓶颈。这里别只盯着堆内存曲线：如果 handle 又把所有事件重新收集到全局切片里，流式读取的收益会被完全抵消。

RawMessage 适合冷字段，不适合所有 JSON

json.RawMessage 会把对应字段的原始JSON片段保留下来，等业务逻辑真的需要用到这个字段时再做解码。比如订单事件里 extra 只有风控重放场景才会读取，完全没必要每次请求都把它展开成深层结构体。

type RiskExtra struct {
    Device string `json:"device"`
    Score  int    `json:"score"`
}

func readRisk(event OrderEvent) (RiskExtra, error) {
    var extra RiskExtra
    if len(event.Extra) == 0 {
        return extra, nil
    }
    if err := json.Unmarshal(event.Extra, &extra); err != nil {
        return extra, fmt.Errorf("decode risk extra: %w", err)
    }
    return extra, nil
}

它的适用边界也很清晰：RawMessage仍然占用原始片段的内存空间，后续二次解析还会产生额外开销。如果每次请求都要访问 extra，直接解成结构体反而更简单；如果冷字段体积很大，还要在入口层设置请求体大小上限，别把“延迟解析”误当成“没有内存成本”。

改动前后怎么验收，才不会被一次基准误导

建议至少准备小对象、长数组、包含大冷字段三组样本，每组分别测试完整解码和逐条消费两种模式。运行基准测试时固定Go版本和机器负载，连续执行几次取中位值，别拿开发机单次测试的结果直接承诺线上收益。

• 普通接口响应场景：先对比 Unmarshal 的代码复杂度和可读性，没必要为了微优化降低可维护性。
• 大数组导入场景：验证逐条 Decoder 确实降低了峰值内存，同时检查下游逻辑有没有悄悄缓存全量结果。
• 冷字段占比高的场景：对比 RawMessage 的B/op和二次解析耗时，确认这类字段的实际访问比例足够低。
• 线上复查环节：同时观测请求体大小、GC次数、堆峰值、P95延迟和错误率多个维度的指标。

一个很实用的判断标准是：只有当基准测试里的输入规模和线上最常见的请求形态高度接近，优化结果才值得推灰度上线。否则优先保留清晰易懂的完整解码写法，等实际监控指标证明内存或延迟确实是瓶颈之后，再小范围调整实现逻辑。

常见问题

json.Decoder 一定比 json.Unmarshal 快吗？

不一定。如果最终都要生成完整结果切片，两者性能差距会很小；Decoder的核心价值是从流中逐项读取数据，减少完整结果同时常驻内存的需求。

RawMessage 会不会把内存占用降到零？

不会。它只是保留原始JSON字节，省下的是不必要的深层对象分配开销；原始字节片段本身依然需要占用对应大小的内存空间。

怎么判断 JSON 解析优化值得做？

用和线上形态接近的样本运行基准测试，再结合堆峰值、GC频率、P95延迟和错误率多个指标综合判断。只看ns/op这个单指标，很容易漏掉大请求带来的隐性内存压力。

把选择规则留在代码评审里

这三种解析方式不是替代关系：完整对象解码优先保证可读性，Decoder解决大数组的处理边界问题，RawMessage解决低频字段的延迟展开需求。把测试样本、基准输出和边界条件一起写到变更说明里，后续业务调整数据规模或字段结构时，团队也有明确的依据来判断旧的优化策略是否仍然成立。