shouldbindjson要求嵌套结构体所有字段必须导出（首字母大写）且每层显式声明json标签，否则静默丢弃；指针字段可解析空对象为零值，omitempty支持可选嵌套，自定义反序列化需手动调用json.unmarshal。
为什么 binding:"json" 对嵌套结构体不生效
Gin 默认用 ShouldBindJSON 解析请求体，但如果你的结构体字段没加 json 标签，或嵌套字段没导出（首字母小写），Gin 就完全忽略它们——不是报错，而是静默丢弃。常见现象是：前端传了 {"user":{"name":"Alice","age":30}}，后端 User 字段却始终为空。
- 必须确保所有嵌套字段都是导出字段（首字母大写）
- 每一层结构体都要显式声明
json标签，比如type User struct { Name string `json:"name"` } - 如果嵌套字段是指针（如
*Address），Gin 仍能解析，但空对象{"address":{}}会初始化为零值而非nil
如何正确声明嵌套结构体并绑定
别把嵌套逻辑塞进 handler 里手动解，直接在结构体定义时对齐 JSON 层级。Gin 的反射绑定依赖字段标签和可导出性，不是靠类型名匹配。
type CreateUserRequest struct {
UserID int `json:"user_id"`
User User `json:"user"`
}
type User struct {
Name string `json:"name"`
Age int `json:"age"`
}
- 调用
c.ShouldBindJSON(&req)后，req.User.Name就能拿到值 - 如果想允许部分字段缺失，给嵌套结构体字段加
omitempty，比如User User `json:"user,omitempty"` - 注意：Gin 不支持嵌套结构体的自定义 UnmarshalJSON，如有特殊解析逻辑（如兼容旧版字段名），得改用
json.Unmarshal手动处理
ShouldBindJSON 和 BindJSON 的区别在哪
两者都做 JSON 解析，但错误处理方式不同：ShouldBindJSON 在解析失败时返回 error，而 BindJSON 会自动写入 400 响应并终止后续逻辑。多数场景推荐用 ShouldBindJSON，便于统一错误响应格式。
-
ShouldBindJSON：适合需要自定义错误码、日志或 fallback 处理的场景 -
BindJSON：适合快速原型，但一旦出错就无法干预响应内容 - 无论哪个，嵌套结构体的绑定行为完全一致——失败原因只取决于结构体定义是否合规，不取决于选哪个方法
嵌套数组或 map 怎么处理
Gin 能原生解析嵌套数组和 map，但要注意字段类型必须精确匹配。比如 JSON 中 "tags":["go","web"]，结构体字段就得是 Tags []string；若写成 Tags []interface{}，虽然不报错，但取值时要类型断言，容易 panic。
- 数组嵌套：直接声明
Orders []Order `json:"orders"`，Gin 会递归绑定每个Order - map 嵌套：用
Meta map[string]string `json:"meta"`，但 Gin 不校验 key 是否合法，仅做字符串映射 - 混合嵌套（如
[]map[string]interface{}）虽能解析，但失去类型安全，调试困难，不建议在正式接口中使用
嵌套越深，结构体定义越容易漏掉某个 json 标签或导出首字母，上线前最好用实际请求体跑一遍单元测试，别只靠眼查。
