gin嵌套结构体字段不触发验证，因c.shouldbind默认不递归验证子结构体，需在外层字段显式添加binding标签（如required），且指针字段为nil时若未加required则直接跳过校验。
嵌套结构体字段不触发验证？检查 binding 标签是否漏写
默认情况下，Gin 的 c.ShouldBind 不会递归验证嵌套结构体的字段——哪怕子结构体本身定义了 binding 标签，父结构体没显式声明，验证就只停留在外层。这是最常被忽略的坑。
- 必须在外层字段的 tag 中显式加上
binding:"required"（或其他规则），否则 Gin 完全跳过该字段的绑定与验证 - 子结构体内部的
binding标签只有在被上级“拉进来”后才生效 - 如果子结构体指针字段为
nil，且未加required，Gin 会直接跳过，不会报错也不会校验其内部字段
正确写法示例：
type Address struct {
City string `json:"city" binding:"required,min=2"`
Zip string `json:"zip" binding:"required,len=6"`
}
type User struct {
Name string `json:"name" binding:"required"`
Age int `json:"age" binding:"required,gte=18"`
Addr Address `json:"addr" binding:"required"` // ← 关键：这里必须加 binding
// Addr *Address `json:"addr" binding:"required"` // 若用指针，也一样要加 binding
}
ShouldBindJSON 对嵌套结构体验证失效？确认 Content-Type 和方法匹配
c.ShouldBindJSON 只处理 application/json 请求体，且要求整个 payload 能完整映射到目标结构体。嵌套验证失败，往往不是 validator 问题，而是绑定阶段就出错了。
- 若请求 header 中
Content-Type缺失或不是application/json，ShouldBindJSON会直接返回invalid content type错误，根本走不到验证逻辑 - 嵌套字段名大小写、下划线风格与 JSON key 不一致时，字段值为零值（如空字符串、0），但不会报错——验证器看到的是“合法空值”，而非“缺失字段”
- 用
c.ShouldBind替代c.ShouldBindJSON更稳妥：它会自动根据Content-Type切换解析器，对嵌套结构体更友好
跨层级字段校验（比如 password 和 confirm_password）怎么写？用 StructLevelValidation
单字段标签（如 eqfield=password）只能比较同级字段。一旦密码和确认密码分属不同嵌套层级（例如 User.Credentials.Password 和 User.Confirm.Password），就必须用结构体级别校验。
- 注册校验器时，调用
v.RegisterStructValidation，传入函数和目标结构体类型 - 函数内通过
sl.Current().Interface().(YourStruct)获取实例，手动比对跨字段值 - 报错要用
sl.ReportError，否则错误不会合并进最终err.Error()
示例（校验 User 中两个嵌套密码字段是否一致）：
func userStructLevelValidation(sl validator.StructLevel) {
u := sl.Current().Interface().(User)
if u.Credentials.Password != u.Confirm.Password {
sl.ReportError(u.Credentials.Password, "Credentials.Password", "Password", "password_mismatch", "")
sl.ReportError(u.Confirm.Password, "Confirm.Password", "Password", "password_mismatch", "")
}
}
// 注册
if v, ok := binding.Validator.Engine().(*validator.Validate); ok {
v.RegisterStructValidation(userStructLevelValidation, User{})
}
嵌套结构体中含 slice 或 map 字段，验证容易漏掉边界条件
对 []Address 或 map[string]string 这类字段加 binding:"required"，只保证该字段非 nil；但不会校验 slice 是否为空、map 是否有元素、或其中每个元素是否满足子规则。
-
dive是关键：对 slice/map 内部元素启用验证，例如binding:"required,dive,required"表示 slice 非空且每个元素都非空 -
required+dive组合后，空 slice（[]）会触发错误；nil slice 则由required捕获 - 嵌套 map 的验证需配合
keys和endkeys，例如binding:"required,keys,required,endkeys,dive,required"表示 key 和 value 都不能为空
典型场景：
type Order struct {
Items []Item `json:"items" binding:"required,dive,required"` // ← 每个 Item 都会被验证
}
type Item struct {
Name string `json:"name" binding:"required,min=1"`
Qty int `json:"qty" binding:"required,gte=1"`
}
嵌套验证真正麻烦的不是语法，而是验证时机——绑定失败、字段跳过、空值伪装成“已验证”，这些静默行为比明面上的 panic 更难定位。动手前先用 c.ShouldBind 替掉所有硬编码的 ShouldBindJSON，再逐层检查每个嵌套字段的 tag 是否带 binding，基本能避开 80% 的问题。
