Golang解析复杂JSON嵌套结构方法

解析嵌套JSON首选导出struct配json tag；动态结构用map[string]interface{}加类型断言；复杂/多版本字段用json.RawMessage延迟解析；注意数字默认float64、避免伪嵌套与循环引用。

用 json.Unmarshal 解析已知结构的嵌套 JSON

如果 JSON 格式稳定、字段明确，直接定义嵌套 struct 是最安全高效的方式。Go 的 json.Unmarshal 会自动按字段名（或 json tag）递归匹配嵌套对象和数组。

常见错误是忽略字段导出规则（首字母大写）或 tag 拼写错误，导致解析后字段为空。

• struct 字段必须首字母大写（即导出），否则 json 包无法赋值
• 嵌套字段也需是导出 struct，不能用 map[string]interface{} 替代除非必要
• 用 json:"field_name,omitempty" 控制可选字段，避免零值覆盖业务逻辑

type User struct {
    Name  string `json:"name"`
    Info  Info   `json:"info"`
}
type Info struct {
    Age  int    `json:"age"`
    Tags []string `json:"tags"`
}

var u User
err := json.Unmarshal([]byte(`{"name":"alice","info":{"age":30,"tags":["dev","go"]}}`), &u)

用 map[string]interface{} 动态处理未知嵌套结构

当 JSON 字段动态变化（如配置项、API 返回结构不固定）、或仅需读取其中几个深层字段时，硬编码 struct 成本高且易崩。此时用 map[string]interface{} + 类型断言更灵活。

但要注意：JSON 数值默认解析为 float64，直接转 int 会 panic；嵌套 map 需逐层检查 key 是否存在，否则运行时报 panic: interface conversion: interface {} is nil, not map[string]interface{}。

• 每层访问前先做类型断言和非 nil 判断
• 数字字段优先用 float64 接收，再按需转 int 或 int64
• 数组用 []interface{} 接收，遍历时同样要断言元素类型

var data map[string]interface{}
json.Unmarshal(b, &data)
if info, ok := data["info"].(map[string]interface{}); ok {
    if age, ok := info["age"].(float64); ok {
        fmt.Println(int(age)) // 注意：不是直接 int(info["age"].(int))
    }
}

用 json.RawMessage 延迟解析特定嵌套字段

当 JSON 中某一部分结构复杂、版本多变，或只在某些条件下才需要解析时，用 json.RawMessage 可跳过即时解码，把原始字节缓存下来，等真正要用时再调用 json.Unmarshal —— 避免无谓的嵌套解析开销，也方便做 schema 分支处理。

典型场景：Webhook 支付回调中 data 字段可能是订单、退款、转账等不同结构，统一用 RawMessage 接收后再分发解析。

• RawMessage 本质是 []byte，不参与结构体字段初始化
• 不能直接对 RawMessage 做 map 或 struct 断言，必须再次 Unmarshal
• 若后续未解析，它就只是内存里的字节切片，不会触发 panic

type WebhookEvent struct {
    Type string          `json:"type"`
    Data json.RawMessage `json:"data"`
}

var event WebhookEvent
json.Unmarshal(b, &event)
if event.Type == "order.created" {
    var order Order
    json.Unmarshal(event.Data, &order) // 此时才解析
}

嵌套过深或循环引用时的注意事项

Go 的 json 包本身不支持循环引用（会报 json: unsupported type: map[interface {}]interface{} 或栈溢出），也不限制嵌套深度，但实际中超过 10 层嵌套就容易触发 Go runtime 的栈保护或解析超时。

真正棘手的是“伪嵌套”：比如服务端返回的 "data": "{...}"（字符串里又包了一层 JSON），这种不是语言层面的嵌套，而是业务层逃逸，必须手动 json.Unmarshal 两次。

• 用 json.Valid() 提前校验字节是否为合法 JSON，避免后续解析 panic
• 对不可信输入（如用户上传 JSON），务必设解析超时或深度限制（可用第三方库如 go-json 的 MaxDepth 选项）
• 别依赖 encoding/json 自动处理 HTML 实体或 base64 编码字段——那是业务逻辑，不是 JSON 规范

嵌套本身不难，难的是区分哪些是协议约定的嵌套、哪些是业务混淆的字符串嵌套，以及是否真的需要全部展开。多数时候，RawMessage + 按需解析，比一上来就 flatten 所有字段更可持续。