ShouldBindJSON可处理嵌套结构体，但需逐层正确配置json标签，子结构体字段必须为公有且均带匹配标签，否则绑定失败；应避免混用ShouldBind，校验需递归标注binding标签。
ShouldBindJSON 能直接处理嵌套结构体，但字段标签必须逐层写对
嵌套结构体绑定失败，90% 是因为子结构体字段没加 json 标签，或者标签名和 JSON 字段不一致。Gin 不会自动“穿透”嵌套结构体去猜字段映射，它只按你写的标签一层层反序列化。
比如客户端发来：
{"user":{"name":"Alice","age":25},"status":"active"}
对应结构体必须这样写：
type User struct {
Name string `json:"name"`
Age int `json:"age"`
}
type CreateRequest struct {
User User `json:"user"`
Status string `json:"status"`
}
-
User字段本身也要带json:"user"，否则 Gin 会忽略整个user对象 - 子结构体
User的每个字段都得有json标签，不能只在顶层结构体写 - 如果子结构体字段是私有的（首字母小写），即使有标签也无法被
json.Unmarshal赋值，Gin 绑定同样失效
ShouldBind 无法可靠处理嵌套 JSON，别混用
ShouldBind 依赖 Content-Type 自动选解析器，但它对嵌套 JSON 的支持很脆弱：当请求头是 application/json 时，它内部会走 jsonBinding；但一旦 Content-Type 缺失、错误或被中间件篡改，它可能 fallback 到 form 解析，导致嵌套字段全为零值且无报错。
- 明确知道是 JSON 请求 → 一律用
ShouldBindJSON，不依赖自动检测 -
ShouldBind更适合表单或查询参数这类扁平数据，不是为嵌套设计的 - 实测中，
ShouldBind在 multipart/form-data + JSON 字符串字段场景下会静默失败，而ShouldBindJSON直接报错，反而更容易定位问题
验证嵌套字段要用 binding 标签递归写
嵌套结构体的校验不会自动继承，binding:"required" 只作用于当前字段，不检查其内部字段是否合法。想让 User 必填且 User.Name 也必填，得两层都标：
type CreateRequest struct {
User User `json:"user" binding:"required"` // 这行保证 user 不为 nil
Status string `json:"status" binding:"required"`
}
type User struct {
Name string `json:"name" binding:"required"` // 这行才真正校验 name 字段
Age int `json:"age" binding:"min=18"`
}
- 如果只在顶层写
binding:"required"，空的{"user":{}}也能通过 - Gin 不支持
binding:"required.name"这类路径式写法，必须拆到子结构体上 - 嵌套层级深时，建议把子结构体单独定义并复用，避免重复写校验逻辑
数组嵌套需额外注意切片标签和空数组行为
绑定 JSON 数组到结构体切片时，ShouldBindJSON 默认接受 null 或缺失字段为 nil 切片，但业务常需要“空数组”而非 nil —— 这会影响后续 len() 判断或循环逻辑。
- 用
[]User `json:"users" binding:"required"`只校验字段存在，不阻止"users":null - 若需强制非空数组，得自定义验证函数，或在绑定后手动检查：
if req.Users == nil { req.Users = []User{} } - 嵌套数组中的元素仍需各自带
json和binding标签，和单个嵌套结构体规则一致
