Go encoding/json RawMessage 延迟解析如何避免底层字节别名：Marshal 与 Unmarshal 边界

线上接口把同一份 JSON 的公共字段和业务字段分开处理时，json.RawMessage 很顺手：先读出 kind，再决定把 payload 解成哪种结构。真正容易踩坑的是字节所有权——反序列化会复制输入，序列化却直接返回已有字节。把这两个方向混为一谈，修改复用的切片后就可能得到难以定位的 JSON 变化。

记住一条边界：UnmarshalJSON 会把输入复制进 RawMessage，而 MarshalJSON 返回当前 RawMessage 的字节；需要长期保存或跨协程传递时，业务代码仍应把它当作不可变数据使用。

先把 RawMessage 放在公共字段与业务字段之间

假设消息只有一个稳定的 kind 字段，payload 会随业务类型变化。先把 payload 留成原始 JSON，可以避免为了识别类型而先解成 map[string]any，也不会在数字、字段顺序或嵌套结构上过早丢失信息。

type Envelope struct {
    Kind    string          `json:"kind"`
    Payload json.RawMessage `json:"payload"`
}

var msg Envelope
if err := json.Unmarshal(input, &msg); err != nil {
    return err
}

switch msg.Kind {
case "user.created":
    var event UserCreated
    if err := json.Unmarshal(msg.Payload, &event); err != nil {
        return err
    }
    return handleUserCreated(event)
default:
    return fmt.Errorf("unsupported kind %q", msg.Kind)
}

这里的调用链很短：json.Unmarshal 先填充 Envelope.Payload，分支确认 Kind 后，再对同一段 Payload 做第二次定向解码。第二次解码前，原始字节仍然保留，便于记录原文或转发。

UnmarshalJSON 为什么能隔离输入缓冲区

标准库里的 RawMessage.UnmarshalJSON 会执行 *m = append((*m)[0:0], data...)。这段写法会复用接收者已有容量，但会把本次输入的内容复制进去。因此，调用者之后重用 input，不会直接改写已经保存的 msg.Payload。

input := []byte(`{"kind":"user.created","payload":{"id":7}}`)
var msg Envelope
if err := json.Unmarshal(input, &msg); err != nil {
    panic(err)
}

input[0] = 'X' // 改的是输入；msg.Payload 不会因此变成另一份内容
fmt.Println(string(msg.Payload))

但“标准库做过一次复制”不等于业务代码可以随意修改 RawMessage。如果同一个对象被缓存、日志记录和异步任务共同使用，最稳妥的约定仍然是只读；确实要编辑时，先复制一份新的 []byte。

需要独立所有权时怎么写

func cloneRawMessage(src json.RawMessage) json.RawMessage {
    return append(json.RawMessage(nil), src...)
}

cloneRawMessage 把“这份数据由新调用者负责”写进代码。它适合放在缓存入口、消息投递入口或把数据交给可能修改切片的旧接口之前。

MarshalJSON 的返回值不要当成可编辑工作区

RawMessage.MarshalJSON 对 nil 返回字面量 null，对非 nil 值则返回当前的 RawMessage。这意味着序列化阶段没有替你建立一份可编辑副本。json.Marshal 会负责把结果写入自己的编码流程，但自定义 Marshaler 的调用方不应依赖“拿到返回值后修改它”来改变原对象。

raw := json.RawMessage(`{"ok":true}`)
encoded, err := json.Marshal(raw)
if err != nil {
    return err
}
fmt.Println(string(encoded)) // {"ok":true}

var empty json.RawMessage
encoded, err = json.Marshal(empty)
if err != nil {
    return err
}
fmt.Println(string(encoded)) // null

需要改变内容时，重新构造新的 RawMessage，或者先解码到明确的结构体再编码。这样比直接改动共享字节更容易审查，也不会让缓存里的旧值被悄悄污染。

一张小表厘清四个边界

常见误区：复制发生在哪里

把 RawMessage 当成普通字符串

它不是带编码保证的文本容器，而是一段 JSON 编码字节。需要确认内容合法时，仍要通过 json.Valid 或再次解码验证。

只测成功路径，不测输入复用

测试中可以在解码后改写输入缓冲区，再断言 Payload 保持不变；这能直接验证你依赖的是复制边界，而不是偶然的底层数组。

用 nil 表示“没有 payload”却忘了 JSON 结果

nil RawMessage 会走 null。如果协议要求省略字段、输出空对象或输出空数组，应通过结构体标签和明确的值表达，而不是把三种语义混在一起。

延伸问答

RawMessage 适合做 JSON 缓存吗？

适合缓存尚未决定具体结构的 JSON 片段，但缓存边界最好保存独立副本，并在读出时按只读数据处理。

UnmarshalJSON 会复制整个输入 JSON 吗？

它会复制赋给该 RawMessage 字段的那段 JSON 数据，不是让每个业务字段都共享原始输入。真正的内存占用仍应结合消息大小和缓存生命周期评估。

RawMessage 能不能直接拼接 JSON？

可以在确认每一段都来自可信且合法的 JSON 后组合；否则优先使用结构体或 json.Marshal 生成，避免拼接出语法错误或意外字段。

把所有权写进测试与接口

遇到“偶尔变了”的 JSON，先查调用链上谁持有这段 []byte，再区分问题发生在 UnmarshalJSON 的输入复制，还是发生在业务代码复用 RawMessage 的阶段。对外传递时显式 clone，对 nil、空对象、空数组分别断言，通常就能把这个边界变成一条可维护的工程约定。