map[string]interface{} 是处理动态 JSON 的首选，因其能直接承载任意 JSON 结构；需注意数字转 float64、嵌套类型断言、非法键名访问限制；反射构造结构体时须确保字段导出、传地址、正确推导嵌套类型与切片。
Go 里处理动态 JSON，别硬写结构体——多数时候 map[string]interface{} 就够用；真要转成结构体再用反射，得绕开几个关键坑，否则一跑就 panic 或字段全零值。
为什么 map[string]interface{} 是首选起点
第三方 API 返回结构常变、带扩展字段、甚至键名含连字符（如 "user-id"），这时预定义结构体维护成本高，且 json.Unmarshal 对缺失字段静默忽略、类型错配也不报错。
-
map[string]interface{}是 encoding/json 原生支持的通用容器，能直接承载任意 JSON 对象 - JSON 数字一律转为
float64，不是 int——业务中需显式转换，比如int(v.(float64)) - 嵌套对象变成
map[string]interface{}，数组变成[]interface{}，访问时必须逐层断言，不能跳步 - 键名非法（如数字开头或含破折号）不会导致解析失败，但后续取值得用
m["2024_config"]这种字面量写法，不能点语法
什么时候该用反射构造结构体？
当你需要字段类型安全、支持 tag 验证（如 json:",omitempty"）、或要对接 ORM/validator 等依赖结构体类型的库时，map[string]interface{} 就不够用了。
- 核心是
reflect.StructOf：它接受[]reflect.StructField，每个字段必须有合法 Go 标识符名（"UserID"可，"user-id"不可） - JSON 键名到字段名的映射需手动标准化，常见做法是把
"user_id"转成"UserID"，再塞进Tag字段 - 嵌套对象不能递归调用
StructOf——得先解析子 JSON 得到map[string]interface{}，再基于它的键推导子字段，最后作为reflect.StructField.Type填入父级 - 数组字段类型不能写死
[]interface{}，得看第一个元素类型：如果是字符串数组，就用reflect.SliceOf(reflect.TypeOf(""))
json.Unmarshal 传参不加 & 就白干
这是最常踩的坑：传值进去，反序列化完变量还是零值。因为 json.Unmarshal 必须拿到可寻址的内存地址才能写入数据。
立即学习“go语言免费学习笔记（深入）”；
- 对结构体变量，必须传
&v，而不是v - 对 map 或 slice 变量，同样要传地址：
&m或&s，否则解析结果不会写入原变量 - 用反射构造的类型也一样：
reflect.New(dynamicType).Interface()返回的是指针，直接传给Unmarshal即可；若用reflect.Zero(dynamicType).Interface()，得到的是值类型，必须再取地址 - 如果目标是切片，别先
make([]T, 0)再传&slice——反射构造时应直接用reflect.New(reflect.SliceOf(reflect.PtrTo(structType)))，确保类型信息完整
字段名不导出，反射就看不见
哪怕你用反射去遍历结构体，小写字母开头的字段（如 name string）在 reflect.Value 层面是不可见的，CanSet() 返回 false，赋值会 panic。
- 所有待反序列化的字段，首字母必须大写（即导出）
- struct tag 如
json:"user_name"只影响键名映射，不改变字段可见性 - 嵌套结构体字段也要导出，否则深层字段会被
Unmarshal静默跳过 - 临时调试时想快速查看字段，可用
reflect.ValueOf(v).Elem().NumField()检查实际可见字段数，少于预期基本就是没导出
动态 JSON 解析真正的复杂点不在语法，而在类型推导边界：JSON 数字该当 int 还是 float64？空数组和 null 怎么区分？这些都得靠业务逻辑补足，反射本身只管“怎么放”，不管“该放什么”。
