Go解析嵌套JSON必须严格匹配结构体层级与字段标签：字段首字母大写、显式json:"key"标签、嵌套对象用独立命名struct，否则静默为零值；动态键用map[string]T，混型数组用json.RawMessage延迟解析。
嵌套结构体定义必须与JSON字段严格匹配
Gin 默认用 json.Unmarshal 解析请求体，它依赖 Go 结构体标签（json:"field_name"）做字段映射。如果 JSON 里有 user_info 字段，而结构体里写成 UserInfo 却没加 json:"user_info"，解析后该字段就是零值，且无报错——这是最常被忽略的静默失败点。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 嵌套层级深时，逐层定义结构体，避免全写在顶层；比如
Address、Contact单独建 type，再被User引用 - 所有字段加
json标签，即使大小写一致也别省略（Go 的首字母大写导出规则和 JSON 小写下划线习惯不兼容） - 可选字段用指针或加
omitempty，例如Age *int `json:"age,omitempty"`，避免零值覆盖业务默认逻辑 - 遇到 key 含点号（如
"order.id"）或中括号（如"tags[0]"），标准json标签无法处理，得改用第三方库如go-json-unmarshal或预处理字符串
使用 c.ShouldBindJSON() 而非 c.BindJSON()
c.BindJSON() 遇到解析失败会直接返回 400 错误并终止中间件链；而 c.ShouldBindJSON() 只返回 error，由你决定怎么处理——这对嵌套结构尤其关键：字段缺失、类型错位、空数组 vs null 等问题，往往需要定制化提示而非统一 400。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 始终用
c.ShouldBindJSON(&req)，检查 error 并记录原始 body（c.Request.Body需提前用ioutil.ReadAll缓存，因为 Body 只能读一次） - 不要只判断
err != nil，要区分是语法错误（*json.SyntaxError）、类型不匹配（*json.UnmarshalTypeError）还是字段不存在（通常无 error，只是字段为零值） - 对嵌套 map 或 slice，若不确定长度或结构，先用
map[string]interface{}接收，校验后再转结构体，避免 panic
处理 null、空对象、缺失字段的边界情况
前端发来的 JSON 经常不规范：比如 "profile": null，但你的结构体字段是 Profile ProfileInfo（非指针），解出来就是全零值，无法区分“用户没传”和“用户明确传了 null”。更糟的是，某些 SDK 把空对象序列化成 {}，而另一些生成 null，行为不一致。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对可能为
null的嵌套对象，一律用指针类型，例如Profile *ProfileInfo `json:"profile"`，这样nil就代表 JSON 中是null或字段缺失 - 对 slice 字段，避免用
[]string接收，改用*[]string，否则"tags": null和"tags": []都变成空 slice，无法区分 - 用
json.RawMessage延迟解析可疑字段，比如Data json.RawMessage `json:"data"`，后续按需json.Unmarshal并捕获具体错误位置
调试时快速定位解析失败位置
Gin 不提供字段级错误信息，默认 error 只说 “invalid character …”，根本看不出是哪个嵌套字段出问题。靠打印整个 body 或加断点效率极低。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 启用 Gin 的 debug 模式（
gin.SetMode(gin.DebugMode)）能多输出一些上下文，但依然不精确 - 把请求 body 读成
[]byte后，先用json.Valid()判断是否合法 JSON，再用json.Unmarshal单独测试，配合json.SyntaxError.Offset定位字符位置 - 对复杂结构，写单元测试用已知 bad case 触发 error，例如故意把
"age": "abc"放进 JSON，观察 error 类型和消息，提前建立错误模式认知
json.RawMessage + 手动校验，比硬扛反射解析更稳。 
