shouldbind 不校验或报错取决于 content-type 与结构体标签是否匹配：content-type 决定绑定器（json/form/query），仅绑定成功后才执行 binding 标签校验；若标签不匹配（如表单用 json:"name"），字段未赋值，validator 不触发。
ShouldBind 为什么有时不校验，有时报错？
因为 ShouldBind 的行为取决于请求的 Content-Type 和结构体标签是否匹配。它不是“固定走 JSON 解析”，而是先协商格式，再选绑定器，最后才触发 validator 校验。
常见现象：POST 表单提交却用 json:"name" 标签 → 字段始终为空，binding:"required" 却没报错 → 实际是绑定阶段就失败了，但 validator 没机会运行（因为字段没被赋值）。
- GET 请求（无 body）默认走
ShouldBindQuery+ShouldBindForm合并尝试，只认form:或无标签字段 - Content-Type 是
application/json才触发 JSON 绑定器，此时才读json:标签 -
binding标签只在校验阶段生效；若绑定阶段字段根本没被写入（比如标签不匹配），validator 就不会检查它 - 想强制走某一种绑定，用
c.ShouldBindJSON(&v)或c.ShouldBindQuery(&v)更可靠
结构体标签怎么写才不踩坑？
一个字段同时支持多种输入源（比如前端可能发 JSON，也可能发表单），不能只写 json:，否则表单提交时字段丢失。
正确写法是显式声明各来源映射：
type User struct {
Name string `json:"name" form:"name" binding:"required"`
Email string `json:"email" form:"email" binding:"required,email"`
ID int64 `uri:"id" binding:"required"`
}
-
uri:只用于路径参数（如/user/:id），必须配合c.ShouldBindUri(&v)或路由定义中已注册:id -
header:对应请求头字段，如Authorization，需小写转驼峰（header:"X-Request-ID"→ 字段名用XRequestID） - 不要混用
json:和form:在同一个字段却给不同名字（如json:"user_name" form:"username"），会导致绑定歧义 - 空字符串、零值字段默认不触发
required—— 它只判断字段是否被成功赋值，不是判断值是否为空
校验失败错误信息太难读怎么办？
默认的 err.Error() 返回的是 validator 的原始路径式报错，比如 Key: 'User.Email' Error:Field validation for 'Email' failed on the 'email' tag，前端没法直接展示。
- 用
err.(validator.ValidationErrors)类型断言，遍历每个错误项，提取Field()、Tag()、Value() - 避免直接返回整个
err.Error()，尤其在生产环境——容易泄露字段名和校验逻辑 - 自定义错误格式示例：
map[string]string{"email": "邮箱格式不正确"}，比原始错误更友好 - 注意：只有 validator 触发的错误才可转成
ValidationErrors；绑定失败（如 JSON 解析失败）返回的是json.UnmarshalTypeError等底层错误，需单独处理
嵌套结构体或切片怎么绑定校验？
嵌套结构体默认支持，但切片字段容易被忽略 —— ShouldBind 不会自动初始化 slice，空切片或 nil 切片都可能绕过校验。
- 嵌套结构体字段必须是非指针（
User User）或带binding:"required"的指针（User *User），否则内部校验不触发 - 切片字段如
Roles []string，加binding:"required,gt=0"可限制非空，但前提是请求里真传了该字段（否则字段为 nil，校验跳过） - 若请求体是
{"roles":[]}，切片被初始化为空，gt=0失败；若是{}，切片为 nil，required不生效 —— 这是 validator 的设计限制 - 解决办法：对关键切片字段加
omitempty并手动判空，或改用指针切片*[]string强制区分“未传”和“传了空数组”
