最省事方案是用 json.Unmarshal 解析未知 JSON 到 map[string]interface{}，它能兜住任意合法结构且零依赖；但需注意数字默认为 float64、null 为 nil、嵌套对象/数组需逐层断言，避免强转 panic。
Go 里用 json.Unmarshal 直接解析未知结构到 map[string]interface{} 最省事
遇到字段名不固定、嵌套层级不确定的 JSON，硬写结构体只会反复改代码。直接上 map[string]interface{} 是最稳妥的第一步——它能兜住任意合法 JSON，且标准库零依赖。
常见错误是试图把 map[string]interface{} 强转成自定义 struct，结果 panic：panic: interface conversion: interface {} is map[string]interface {}, not MyStruct。别转，先用再判。
- 所有数字默认解析为
float64，哪怕 JSON 里写的是"age": 25，取值时得显式转int或int64 - 布尔值和字符串能直取，但要注意空值：JSON 的
null会变成nil，取前必须判空 - 嵌套对象继续是
map[string]interface{}，数组则是[]interface{}，类型断言要一层层来
需要结构体语义时，用 json.RawMessage 延迟解析
有些字段内容固定但位置不固定（比如不同 API 返回的 data 字段可能是对象也可能是数组），这时候不能全用 map，否则后续逻辑全是类型断言和 if 判断。
json.RawMessage 把一段 JSON 字节流原样存下来，等真正用到那个字段时再调 json.Unmarshal，既保结构体类型安全，又绕过提前定义结构的限制。
- 声明字段时用
Data json.RawMessage `json:"data"`，不是interface{} - 反序列化后，再根据业务判断
Data实际类型：json.Unmarshal(Data, &obj)或json.Unmarshal(Data, &arr) - 注意：
json.RawMessage不会自动处理 UTF-8 BOM，如果源数据带 BOM，需先 strip 否则解析失败
反射动态映射到结构体？小心 reflect.StructField.Anonymous 和 tag 冲突
真要用反射把 map 数据塞进 struct，别手写递归赋值——用 mapstructure 库更稳。但它默认行为和直觉有偏差，容易踩坑。
典型问题：结构体里嵌了匿名字段（比如 type User struct { Base `json:",inline"` }），mapstructure 默认不展开，导致子字段映射失败。
- 启用内联必须显式配置：
mapstructure.DecodeHook(mapstructure.StringToTimeHookFunc("2006-01-02"))不管用，得加DecoderConfig{WeaklyTypedInput: true, Result: &u, DecodeHook: ...}并设TagName: "json" - 字段 tag 里写了
json:"-"或json:"name,omitempty"，mapstructure会尊重，但omitempty只影响序列化，不影响反向映射 - 字段名大小写敏感：map 里的
"user_name"不会自动匹配 struct 的UserName，除非配Metadata或自定义DecodeHook
性能差在哪？map[string]interface{} 解析比结构体慢 3–5 倍
不是不能用，而是得清楚代价。标准库对已知结构体做了大量优化（如字段偏移预计算），而 map 每次都要做哈希查找 + 类型检查 + 内存分配。
压测过 10KB 典型响应体：结构体解码约 80μs，map[string]interface{} 稳定在 300–400μs。如果每秒处理上千请求，这部分开销会明显抬高 P99 延迟。
- 高频场景下，宁可多维护几个小结构体（比如
UserResp、AdminResp），也不用一个大map扛所有 -
json.RawMessage虽延迟解析，但内存里存的是原始字节，比map占用少、构造快；只是首次访问时有解析成本 - 别为了“灵活”在内部服务间传
map——上下游契约清晰时，结构体 + Swagger 文档才是可持续的
动态解析真正的难点不在语法，而在字段语义模糊时怎么设计 fallback 行为。比如一个字段有时是字符串、有时是对象，光靠反射或 map 无法决定该走哪条业务分支——这得靠上游约定或额外元数据字段，不是解析层能解决的。
