Go问答：json.RawMessage怎样延迟解析不同结构的 JSON 字段怎样在批处理代码中减少额外分配

json.RawMessage 可以先保存异构 JSON 字段的编码内容，等外层类型字段确定后再解析为具体结构。批处理减少额外分配的重点，是只构造需要的业务对象、逐条消费，并在所有权明确的串行循环内复用临时变量；RawMessage 本身不意味着零拷贝，也不保证比直接解析更快。

官方地址：https://pkg.go.dev/encoding/json

命名信封与延迟载荷模式

设想同一消息流既有计数又有文字说明：外层 kind 用来判断类型，data 随类型改变。我更愿意把外层称作 Envelope，把变化部分保留为 json.RawMessage。这样调度代码不必先把每个载荷拆成 map[string]any，再用类型断言取值。这是组织结构的取舍，不是未经测量的性能结论。

信封域包含 Envelope、Kind 和 Data；业务域包含 Count、Note 和 json.Unmarshal。Envelope 拥有 Kind 与 Data，Data 作为 Unmarshal 的输入，Unmarshal 的目标由 Kind 决定，目标分别是 Count 或 Note。RawMessage 延迟的是业务结构解析，不是让 JSON 语法错误自动消失。

判断何时值得推迟解析

适合的压力来自“外层先能决定是否消费”。例如很多类型只转交或跳过，当前模块只处理少量载荷；此时可以避免为未消费类型创建完整的 map、切片和字符串对象图。如果每一条都要完整解析一次，先留 RawMessage 再 Unmarshal 会增加一层处理，不应默认采用。

另一个压力来自批次规模。把所有消息先解析成 []Envelope 仍会持有整个批次的载荷。逐条读取可缩短已处理数据的存活范围，但不会让单条超大消息变得没有内存成本。本文选择连续 JSON 对象作为输入格式；顶层数组需要另写数组边界读取逻辑。

实现逐条分发

下面代码只使用标准库。Envelope 是复用的信封，Count 和 Note 是当前循环的临时目标。为让缺失字段不继承旧值，每次解码前重置 Kind 和 Data 的长度，解析具体结构前也清零目标。

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
)

type Envelope struct {
    Kind string          `json:"kind"`
    Data json.RawMessage `json:"data"`
}

type Count struct {
    Value int `json:"value"`
}

type Note struct {
    Text string `json:"text"`
}

func consume(r io.Reader) error {
    dec := json.NewDecoder(r)
    var env Envelope
    var count Count
    var note Note
    for {
        // 重置类型字段和长度，保留 RawMessage 的容量供本次串行消费复用。
        env.Kind = ""
        env.Data = env.Data[:0]
        if err := dec.Decode(&env); err != nil {
            if err == io.EOF {
                return nil
            }
            return fmt.Errorf("读取信封：%w", err)
        }
        switch env.Kind {
        case "count":
            // 先清零，防止本条缺少字段时残留上一条的数据。
            count = Count{}
            if len(env.Data) == 0 || bytes.Equal(bytes.TrimSpace(env.Data), []byte("null")) {
                return fmt.Errorf("count 缺少有效 data")
            }
            if err := json.Unmarshal(env.Data, &count); err != nil {
                return fmt.Errorf("解析 count：%w", err)
            }
            fmt.Println(count.Value)
        case "note":
            note = Note{}
            if len(env.Data) == 0 || bytes.Equal(bytes.TrimSpace(env.Data), []byte("null")) {
                return fmt.Errorf("note 缺少有效 data")
            }
            if err := json.Unmarshal(env.Data, ¬e); err != nil {
                return fmt.Errorf("解析 note：%w", err)
            }
            fmt.Println(note.Text)
        default:
            // 未消费的类型不构造业务对象；仍由外层解码器检查 JSON 语法。
            continue
        }
    }
}

func main() {
    // 输入是连续 JSON 对象，不是包着方括号的数组。
    input := []byte("{\"kind\":\"count\",\"data\":{\"value\":7}}\n" +
        "{\"kind\":\"note\",\"data\":{\"text\":\"批次说明\"}}\n")
    if err := consume(bytes.NewReader(input)); err != nil {
        fmt.Println(err)
    }
}

代码中的打印仅表示当前记录被消费。这里不提供本机运行截图或压测数字。实际项目可把打印改为同步业务调用；业务一旦需要保存数据，就必须重新明确哪些切片和对象归业务拥有。示例遇到已知类型的空 data 或 null 会返回错误，未知类型按示例策略跳过；若业务要求拒绝未知类型，应把 default 改成返回错误。

辨认复制与复用的代价

RawMessage 是编码 JSON 值的容器，解码会持有载荷内容；不能把它理解成输入缓冲区上的永久免费视图。标准实现中的 RawMessage 解码复制输入，因此第一阶段仍有字节存储成本。复用已有容量只是减少某些重复申请的机会，不是库契约承诺固定分配次数，也不应绑定某个工具链的内部表示。

复用域包含 env.Data、底层字节容量和当前记录；所有权域包含独立副本、异步消费者和业务结果。env.Data 使用底层容量，当前记录依赖该 Data；独立副本拥有自己的数据，异步消费者只能在所有权受保证时持有相应数据，业务结果由消费者管理。若把 env.Data 直接存进队列，后续解码可能覆盖共享容量。需要保留旧值时，复制相应字节；这笔分配是正确性所需，不能为了“零分配”省掉。

容量还涉及保留问题。一条很大的 data 可能让复用容器长期保留较大数组。可以在消费完后按业务阈值把过大 Data 置 nil，让后续记录不继续持有它；阈值应根据真实消息大小与内存预算设定，不凭空给所有服务固定数字。

反例与选择清单

判断时先写清消费比例、单条大小、是否保留数据以及同步或异步，再比较分配次数、分配字节和存活堆。没有测量就只描述减少无用对象的机制，不报告提速倍数。复用不会替代业务字段检查；例如 value 缺失时 Count.Value 仍为零，若零有特别含义，需要指针字段或自定义存在性规则。

RawMessage 能跳过无效 JSON 吗？

不能将它当成绕过外层语法解析的工具。信封读取必须先成功，已知载荷再接受对应类型和业务要求的检查。

能重复使用同一个业务结构体吗？

能，但要处理缺失字段保留旧状态的问题。示例每次赋零值，复用复杂切片或映射时还需另外定义清理方式。

只读载荷也必须复制吗？

如果容器以后会被再次写入，只读消费者仍可能看到被覆盖的数据。是否复制取决于所有权和生命周期，不取决于消费者有没有修改意图。

接口依据：https://pkg.go.dev/encoding/json#RawMessage；实现阅读入口：https://go.dev/src/encoding/json/stream.go。本文使用 encoding/json 的既有信封写法，不展开其他 JSON 包的迁移。