Go json.RawMessage 怎么延迟解析多种事件体

一个接口同时接收登录、购买、退款等事件时，最稳妥的做法不是把整个 payload 解成 map[string]any，而是先把公共字段和原始 JSON 分开。Go 的 json.RawMessage 会保留这段 JSON，等读出 type 后，再把它解码到对应的结构体。这样既保留了多态，又不会让后续代码充满类型断言。

先拆外层：用 RawMessage 保留不同 payload

事件的 id、type、created_at 通常是稳定的；真正变化的是 payload。把变化部分声明为 json.RawMessage，第一次解码只处理信封，不急着决定它属于哪个业务结构。

package main

import (
    "encoding/json"
    "fmt"
)

type Event struct {
    ID      string          `json:"id"`
    Type    string          `json:"type"`
    Payload json.RawMessage `json:"payload"` // 先保留原始 JSON，等 Type 确定后再解析
}

type LoginPayload struct {
    UserID string `json:"user_id"`
    Method string `json:"method"`
}

type PurchasePayload struct {
    OrderID string `json:"order_id"`
    Amount  int64  `json:"amount"`
}

func main() {
    data := []byte(`{"id":"evt-7","type":"purchase","payload":{"order_id":"ord-9","amount":199}}`)
    var event Event
    if err := json.Unmarshal(data, &event); err != nil { // 第一阶段只验证外层 JSON
        panic(fmt.Errorf("decode event envelope: %w", err))
    }
    fmt.Printf("type=%s payload=%s\n", event.Type, event.Payload)
}

这里的 Payload 仍是一段 JSON 字节数据，而不是已经确定类型的业务对象。它适合做“先路由、后解码”的接收模型；如果所有事件结构完全相同，就没有必要引入这一层延迟。

先读 type，再把 payload 交给具体结构

第二次解码应该发生在类型判断之后。下面的分派函数只返回已知的两种结构，未知类型直接报错；调用方拿到返回值后，可以用类型断言或进一步封装成统一接口。

func DecodePayload(event Event) (any, error) {
    switch event.Type {
    case "login":
        var payload LoginPayload
        if err := json.Unmarshal(event.Payload, &payload); err != nil { // 字段类型不匹配时保留原始错误
            return nil, fmt.Errorf("decode login payload: %w", err)
        }
        return payload, nil
    case "purchase":
        var payload PurchasePayload
        if err := json.Unmarshal(event.Payload, &payload); err != nil { // 购买事件使用自己的结构约束
            return nil, fmt.Errorf("decode purchase payload: %w", err)
        }
        return payload, nil
    default:
        return nil, fmt.Errorf("unsupported event type %q", event.Type) // 未知类型不应静默丢弃
    }
}

json.Unmarshal 对未知字段默认会忽略，因此严格接口可以在具体结构上增加业务校验，或在需要时使用独立的 json.Decoder 配置。关键点是：RawMessage 只延迟选择，不替你完成字段必填、金额范围和权限检查。

区分未知事件和 payload 解码失败

这三种错误的处理策略不同：外层 JSON 损坏通常进入死信或告警；未知 type 需要确认生产者是否升级；具体 payload 解码失败则应记录事件 ID 和类型，避免把敏感原文直接写入日志。不要用一个“解析失败”字符串覆盖全部原因。

如果事件来自不完全可信的来源，可以先检查 len(event.Payload)，再做第二次解码，给单条消息设置大小上限。RawMessage 会让原文暂时留在内存里，它不是流式解析器，也不会自动限制 payload 大小。

把解析函数封装成可扩展的事件分派器

事件种类继续增加时，最容易失控的是一个巨大 switch。小规模接口保留 switch 反而清楚；当事件超过几个且需要独立测试，可以让每个 decoder 负责一种类型，分派器只负责查找和调用。

type Decoder func(json.RawMessage) (any, error)

var decoders = map[string]Decoder{
    "login": func(raw json.RawMessage) (any, error) {
        var v LoginPayload
        if err := json.Unmarshal(raw, &v); err != nil { // 每种事件在自己的 decoder 内处理错误
            return nil, fmt.Errorf("login payload: %w", err)
        }
        return v, nil
    },
}

func Decode(event Event) (any, error) {
    decoder, ok := decoders[event.Type]
    if !ok {
        return nil, fmt.Errorf("unsupported event type %q", event.Type) // 让上层决定丢弃、重试还是告警
    }
    return decoder(event.Payload)
}

这种写法把“选择谁”和“如何解析”分开，新增事件时只注册新的 decoder。无论采用哪种方案，都应保证 RawMessage 不被跨请求缓存，解析成功后尽早转换成业务对象；这样边界清楚，内存占用和错误追踪也更容易控制。

常见问题

RawMessage 和 map[string]any 有什么区别？

RawMessage 保留原始 JSON，适合稍后解码成明确结构；map[string]any 已经把数字、数组和对象变成通用值，读取时需要更多类型断言。

第二次 Unmarshal 会不会重复解析很慢？

它确实会再扫描 payload，但换来的是类型清晰和可维护的校验边界。若 payload 很大，应考虑限制大小或改用流式协议，而不是为了省一次解析退回通用 map。

未知 type 应该忽略还是返回错误？

由协议约定决定。面向可演进生产者时可以记录并进入兼容分支；必须保证投递成功时，则应返回可观测的“不支持类型”，不要静默当作成功。

记住这条边界：第一次解码识别事件信封，第二次解码识别业务 payload，最后才做业务校验。json.RawMessage 的价值就在于把这三个决策拆开。