Go json.RawMessage 怎样延迟解析不同类型的 payload

把外层消息的 payload 声明为 json.RawMessage，先解码 type，再按它选择具体结构进行第二次解码。这样可以保留载荷的 JSON 字节，推迟具体类型的解释；外层 JSON 的语法仍需有效，不能把延迟解析当成跳过错误检查。

官方文档：https://pkg.go.dev/encoding/json#RawMessage。以下使用 encoding/json 的常规接口，不需要第三方包。

先约定信封与可接受的载荷

以一个素材编辑服务为例：重命名消息需要 name，调整尺寸消息需要 width 和 height。如果一开始把载荷写成固定结构，另一种消息就不好表达；若先放进通用字典，业务层又要反复处理动态类型。

这里定义 Envelope 为信封，包含 Type 与 Payload；后者保留原始 JSON 值。类型选择只允许 RenamePayload 和 ResizePayload，分别对应两项业务。协议还要求payload必须是非null对象，这是应用约定，不是RawMessage的内置限制。

按类型二次解码并逐层返回错误

下面是一份完整的 main.go 示例。它把信封解码、载荷解码和业务条件分开：任一层失败，都返回空结果和错误，避免调用方继续使用部分填充的对象。代码给出使用方式，没有附运行记录。

package main

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

type Envelope struct {
    Type string `json:"type"`
    Payload json.RawMessage `json:"payload"`
}
type RenamePayload struct {
    Name string `json:"name"`
}
type ResizePayload struct {
    Width int `json:"width"`
    Height int `json:"height"`
}

func parseMessage(data []byte) (string, any, error) {
    // 每次使用新的信封，避免缺失字段继承上一条消息的值。
    var env Envelope
    if err := json.Unmarshal(data, &env); err != nil {
        return "", nil, fmt.Errorf("解析信封: %w", err)
    }
    raw := bytes.TrimSpace(env.Payload)
    if len(raw) == 0 || bytes.Equal(raw, []byte("null")) {
        return "", nil, fmt.Errorf("payload必须存在且不能为null")
    }
    // 本协议只接收对象载荷；RawMessage本身没有此限制。
    if raw[0] != '{' {
        return "", nil, fmt.Errorf("payload必须为JSON对象")
    }

    switch env.Type {
    case "rename":
        var p RenamePayload
        if err := json.Unmarshal(raw, &p); err != nil {
            return "", nil, fmt.Errorf("解析rename载荷: %w", err)
        }
        if p.Name == "" {
            return "", nil, fmt.Errorf("rename.name不能为空")
        }
        return env.Type, p, nil
    case "resize":
        var p ResizePayload
        if err := json.Unmarshal(raw, &p); err != nil {
            return "", nil, fmt.Errorf("解析resize载荷: %w", err)
        }
        if p.Width 

两项成功分支分别返回具体结构值。真正接入时，应在 err == nil 后分派到对应业务函数，不要只看返回的类型字符串。三个早期判断的顺序也有含义：先完成信封解码，再确认载荷存在，最后才选择目标结构。

raw[0] 的检查建立在外层解码成功且载荷非空的前提上；它只约束对象形状，不替代二次解码。字符串、数组或数字也可以成为合法RawMessage，只是本示例协议不接收。

保留字节时明确谁拥有底层数组

官方源码展示了常规实现中 UnmarshalJSON 对输入数据的复制：https://go.dev/src/encoding/json/stream.go。通过正常解码得到的字段，不应与“把已有切片直接转成RawMessage”混为一谈。

// 直接转换只改变切片类型，调用方仍然持有底层数组。
raw := json.RawMessage(input)

// 异步保存前复制，避免input被缓冲池复用或被调用方修改。
owned := append(json.RawMessage(nil), raw...)

// 同一份raw赋值给另一个变量，也只是共享底层数组。
alias := owned
_ = alias

这段是函数体内的切片使用片段，其中 input 为已有字节切片。三个对象关系要分别理解：input 与 raw 共享原数组；owned 通过复制持有另一份字节；alias 又与owned共享数组。结构体赋值也不会自动深复制其中的切片。

若复用同一个信封对象反复解码，不应长期保存其旧Payload切片并假定永不改变；实现可能复用原有容量。需要放入异步队列或长期缓存时，在交接处复制，随后将该份数据视作只读。并发读写同一数组仍需要同步，RawMessage不是并发容器。

接入业务前核对失败分支

生产入口还应在读取请求体时限制大小；RawMessage会保留字节，并非节省所有内存的流式方案。上面的函数接收已经读入的切片，因此不能替网络入口限制读取量。错误记录应保留处理阶段和可追踪的请求标识，不直接记录整份载荷中的用户数据。

本例使用默认解码规则，不承诺拒绝未知字段、重复键或所有不符合业务规范的名字。若协议另有严格约束，应分别实现；不能因为用了RawMessage就宣称完成输入加固。延迟的是结构选择，不是责任。

常见问题

RawMessage会自动识别payload类型吗？

不会。识别依据是外层Type和应用的分支规则，新增类型时还需要对应的目标结构及业务条件。

为什么不用[]byte保存payload？

RawMessage具有JSON编解码语义，可以保存一个完整JSON值；普通字节切片不等价。选择它是为了保留JSON片段，而不是把载荷当二进制数据。

第一次解码成功，第二次还会失败吗？

会。JSON语法有效的字符串，仍然不能直接填进要求整数的宽度字段。调用方必须检查第二次解码的错误。