嵌套结构体字段没被解析出来，最常见原因是字段未导出（首字母小写）或未正确使用指针类型；必须确保所有嵌套字段首字母大写、显式添加json标签，并对可能为null的字段使用指针类型（如*UserProfile），同时内层结构体也需遵循相同规则。
嵌套结构体字段没被解析出来，怎么办？
嵌套 JSON 解析失败，最常见原因是结构体字段没用指针或没正确嵌套定义。比如前端传 {"user":{"name":"Alice","profile":{"age":28}}}，但 Go 结构体写成 User Profile 字段是值类型而非指针或内嵌结构体，json.Unmarshal 会跳过空对象或零值字段，导致 Profile 里字段全为零。
- 嵌套字段必须声明为结构体类型（不是接口或 map），且字段名首字母大写（导出）
- 若嵌套对象可能为空（
null），对应字段应使用指针，如Profile *UserProfile，否则反序列化时 panic 或静默丢弃 -
json:标签要逐层匹配 key 名，外层结构体的 tag 不影响内层；内层结构体也要有对应 tag，不能只靠字段名 - 避免用
map[string]interface{}代替嵌套结构体——它绕过类型检查，后续取值易出错，且无法用binding验证
c.ShouldBindJSON 对嵌套字段不校验？
默认情况下，c.ShouldBindJSON 只校验顶层结构体的 binding 规则，不会递归校验嵌套结构体字段。比如 User 里有个 Address 字段，即使 Address 结构体里写了 binding:"required"，也不会触发。
- 必须在嵌套结构体字段上显式加
binding:"required"，且该字段本身不能是 nil 指针（否则校验跳过） - 若嵌套字段是值类型（如
Address Address），校验会进入；若是指针（如Address *Address），需额外加dive标签：Address *Address `json:"address" binding:"required,dive"` -
dive是 go-playground/validator 的语法，告诉校验器“钻进去”校验指针指向的结构体 - 没有
dive时，*Address字段为 nil，校验直接通过；为非 nil 时才校验其内部字段
深层嵌套导致解析慢或内存暴涨？
10 层以上的嵌套 JSON 在 Gin 中解析本身不慢，但若结构体定义不当（比如大量未限制长度的 slice 或 map），或前端故意构造畸形数据（如循环引用、超长键名），就可能触发 OOM 或长时间阻塞。
- Gin 默认用标准
encoding/json，不支持深度限制；生产环境建议加中间件预检Content-Length（如限制 ≤ 2MB） - 对已知深度的嵌套结构，避免在结构体中用
map[string]interface{}或interface{}，它们会禁用编译期类型检查，也绕过 validator - 若必须支持任意深度，用
json.RawMessage延迟解析，例如：Data json.RawMessage `json:"data"`，后续按需解码，避免一次性加载全部 - 注意：Gin 的
c.ShouldBindJSON会完整读取 body 并解码，无法流式处理；超大嵌套 JSON 应改用分块上传或 GraphQL 替代
嵌套 JSON 中混用 null 和缺失字段，怎么统一处理？
前端可能传 {"user":{"name":"A","age":null}} 或 {"user":{"name":"A"}}，Go 结构体字段如果是 int 类型，前者会报错 invalid value for int，后者则设为 0 —— 二者语义不同，但 Go 原生 json 包无法区分“字段不存在”和“字段为 null”。
- 用指针类型接收可空字段，如
Age *int `json:"age"`：字段缺失时为nil，显式null时也为nil，语义一致 - 若需区分两者，得用自定义
UnmarshalJSON方法，或改用第三方库如easyjson（但 Gin 不兼容） - 对于布尔、字符串等类型，同理：用
*bool、*string，配合binding:"required"控制是否允许nil - 别依赖
omitempty标签来判断字段是否存在——它只影响序列化，不影响反序列化行为
dive 和 json.RawMessage 这三个点，能避开 90% 的线上问题。 
