为什么 json.Unmarshal 不能直接处理未知结构的 JSON
因为 Go 的 json.Unmarshal 要求目标类型在编译期已知，而“通用解析”意味着你事先不知道字段名、嵌套层级或类型——比如接收第三方 API 返回的任意 JSON，或用户上传的配置片段。硬写结构体不现实，用 map[string]interface{} 又丢掉类型信息和字段校验能力。
常见错误现象：json: cannot unmarshal object into Go value of type []string 或字段全为零值，本质是类型断言失败或嵌套 map 太深导致手动递归崩溃。
- 别试图用多层
map[string]interface{}+ 类型断言拼出结构体——可读性差、panic 风险高、无法复用验证逻辑 - 如果只是临时调试，用
json.RawMessage延迟解析更安全；但要真正“转成结构体”，必须借助反射构造运行时类型 - 注意：反射无法还原 JSON 中缺失字段的默认值（如 struct tag 里的
default:"xxx"），这部分得额外补逻辑
用 reflect.StructOf 动态构建结构体类型的实操要点
reflect.StructOf 是 Go 1.15+ 提供的关键能力，它允许你在运行时定义结构体字段名、类型、tag，再通过 reflect.New 创建实例。这是实现“通用 JSON 转结构体”的核心支点。
使用场景：需要把 JSON 键名映射为结构体字段，同时保留原始类型（string/number/bool/object/array）并支持嵌套。
立即学习“go语言免费学习笔记（深入）”；
- 字段名必须是合法标识符：JSON 键含连字符（
"user-id"）或数字开头（"2024_config"）时，需做标准化（如转驼峰或加前缀），否则reflect.StructOf直接 panic - 嵌套对象不能直接用
reflect.StructOf递归生成——要先解析子 JSON，再构造子类型，最后作为字段类型传入父级reflect.StructField.Type - 数组字段类型不能只写
[]interface{}：得根据 JSON 第一个元素推断真实类型（如[]string或[]map[string]interface{}），否则后续赋值会失败
简短示例：解析 {"name":"alice","age":30} 得到带字段名和类型的结构体描述：
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
fields := []reflect.StructField{
{Name: "Name", Type: reflect.TypeOf(""), Tag: `json:"name"`},
{Name: "Age", Type: reflect.TypeOf(0), Tag: `json:"age"`},
}
dynamicType := reflect.StructOf(fields)
instance := reflect.New(dynamicType).Interface() // → *struct { Name string; Age int }
处理 JSON 类型歧义：number 是 int 还是 float64？
JSON 规范里没有整数/浮点数区分，Go 的 json.Unmarshal 默认把所有数字当 float64 解析。但业务中常需要按 schema 推断——比如字段名含 "id" 或 "count" 就该是 int，而 "price" 或 "rate" 才是 float64。
容易踩的坑：直接用 json.Number 转 int 会丢失精度或 panic；用 float64 存 ID 导致后续比较失败（如 123.0 != 123）。
- 不要依赖
json.Number的字符串表示做正则判断——JSON 解析器可能已四舍五入（尤其大数） - 更稳妥的做法：先用
json.RawMessage拿到原始字节，再用strconv.ParseInt/ParseFloat尝试解析，捕获错误决定类型 - 如果字段有明确语义（如 OpenAPI schema），优先读取
type和format字段，比启发式推断更可靠
性能与兼容性边界：什么情况不该用反射动态建结构体
反射构建类型本身开销不大，但每次解析都走一遍字段推导 + 类型创建 + json.Unmarshal，比预定义结构体慢 3–5 倍，内存分配也更多。不是所有“动态”需求都值得上反射。
使用场景判断：
- 高频调用（如每秒千次以上 API 入参解析）：改用代码生成（
go:generate+jsonschema工具）或固定结构体 +json.RawMessage按需解析 - 仅需读取少数字段：用
gjson库直接路径取值，比建整个结构体快一个数量级 - 需要完整类型安全 + 验证 + 序列化回写：反射方案必须补全
UnmarshalJSON/MarshalJSON方法，否则无法 round-trip
真正难的不是怎么建结构体，而是字段名标准化、类型歧义消解、嵌套深度控制这三件事——它们没法靠一个函数自动搞定，得结合业务规则写判断逻辑。
