嵌套结构体字段不触发验证是因为validator默认不递归校验，需显式添加dive或structonly标签，且所有嵌套字段必须导出（首字母大写），指针类型需注意nil处理，slice校验必须用dive，错误路径应使用StructNamespace()而非Field()。
嵌套结构体字段不触发验证？不是库不支持，而是 validator 默认不递归校验，必须显式加 dive 或 structonly 标签，且所有嵌套字段必须导出（首字母大写）。
嵌套结构体字段为什么没被校验？
常见现象是：顶层字段加了 validate:"required"，但子结构体里的 Email 字段根本没报错，哪怕为空也不拦截。
- 根本原因是 validator 只校验导出字段，小写字段（如
email string）会被完全跳过——不报错、不提示、不校验 - 嵌套结构体字段本身必须是导出类型（
Email string），且其所在字段需带标签，例如：Profile UserProfile `validate:"required"` - 如果只想校验嵌套结构体是否存在，不深入内部字段，用
validate:"required,structonly"；如果要递归校验全部子字段，直接写validate:"required"即可（前提是UserProfile类型本身已注册验证器） - 指针类型（
*UserProfile）更需小心：nil 时跳过子校验，非 nil 时哪怕指向全零值结构体，也会进入子字段校验流程
dive 标签在 slice 中的正确用法
对 []User 这类字段，validate:"required" 只检查 slice 是否为 nil 或长度 > 0，完全不会校验每个 User 元素。
- 必须显式加
dive：Users []User `validate:"required,dive,required"` -
dive后接的规则作用于每个元素，比如validate:"dive,email"表示每个User的Email字段都要满足 email 格式 - 若元素是
[]*User，dive依然生效，但需确保每个指针非 nil；建议配合required控制，或提前初始化为[]*User{}，避免 nil slice 导致 panic - 慎用
dive,omitempty组合：空 slice（[]User{}）不触发dive，但 nil slice 会 panic
错误路径丢失嵌套层级？别只用 Field()
默认 err.Field() 返回的是最内层字段名（如 "Email"），根本看不出它属于 User.Profile.Contact 哪一层，前端无法映射到对应表单项。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 要用
err.StructNamespace()获取完整命名空间，例如"SignUpRequest.User.Profile.Email" - 用
strings.Split(err.StructNamespace(), ".")拆解后，可转成小写蛇形 key（如"user.profile.email"）供前端消费 - 绝对不要手动拼接结构体名和
err.Field()——遇到 slice（如Users[0].Email）或 map 键时极易错位
Gin 中绑定后验证未生效？确认用了 c.ShouldBind 且调用 Validate.Struct()
常见误操作：用 c.Bind() 或 c.ShouldBindJSON() 解析后，直接传指针给 Validate.Var()，结果只校验指针是否为 nil，字段一个都不跑。
- 务必使用
Validate.Struct(req)，且req必须是非 nil 的结构体实例（不是指针） - 若接收的是指针（如
req *SignUpRequest），先判空：if req == nil { return errors.New("request is nil") }，再传*req给Validate.Struct() - 切忌混用
Validate.Var()和Validate.Struct()：Validate.Var()完全无视结构体上下文、omitempty、嵌套逻辑，仅适合校验单个动态值（如从 map 取出的字符串）
真正容易被忽略的点在于：嵌套字段是否导出、slice 是否加 dive、错误路径是否用 StructNamespace() 而非 Field()——这三处任一遗漏，都会让验证“看起来生效了”，实则漏掉关键校验。
