ShouldBind不是万能解析器，它仅依据Content-Type头选择解析器：application/json走json.Unmarshal，表单类型走ParseForm，其他类型默认fallback到表单解析且不报错；结构体字段须导出、tag匹配、类型一致，否则静默填零值。
ShouldBind 不是万能解析器，它只看 Content-Type 头做路由选择，错配就静默填零值——比如发 JSON 却没设 application/json，字段全空还不报错。
ShouldBind 怎么选解析器？只认 Content-Type，不看 body 内容
它内部走三路分支：
-
application/json→ 调用json.Unmarshal，结构体必须带json:"name"tag -
application/x-www-form-urlencoded或multipart/form-data→ 走ParseForm+ 字段映射，依赖form:"username"tag - 其他类型（包括空、
text/plain）→ 默认 fallback 到表单解析，失败也不提示，字段留零值
常见翻车：用 curl -d '{"name":"foo"}' http://localhost:8080/user 却漏掉 -H "Content-Type: application/json"，ShouldBind 就会把整个 JSON 字符串当做一个表单字段去匹配，Name 字段永远是空字符串。
ShouldBindForm 和 ShouldBind 的区别在哪？
ShouldBindForm 强制走表单解析路径，完全忽略请求头，适合你确定要处理 urlencoded 或上传文件的场景；而 ShouldBind 是“有条件地猜”，容易猜错。
立即学习“go语言免费学习笔记（深入）”；
- 上传文件必须用
ShouldBindForm，因为只有它能正确识别multipart/form-data并提取*multipart.FileHeader -
ShouldBind在Content-Type缺失时 fallback 到 form 解析，但它按form:tag 找字段，不是按json:tag - 如果结构体同时写了
json:"name"和form:"username"，而前端传的是name=foo，那绑定不上——字段名对不上
结构体字段导出、tag、类型三者缺一不可
最容易被忽略的三个点：
- 字段首字母小写 → Gin 反射不到，永远零值（
name string不行，必须Name string） -
form:"user_name"但前端发username=foo→ 绑定失败 - 传字符串
"abc"给int字段 →ShouldBindForm返回error，但很多人没检查err != nil就往下跑逻辑 - 嵌套结构体或数组参数（如
user[name]=Tom&user[age]=25）→ShouldBindForm不支持，得自己解析或换库
binding:"required" 是校验开关，不是绑定开关
ShouldBind 自己不校验，只负责“把数据从请求里掏出来”。如果字段缺失或为空，它照样返回 nil，只有加上 binding:"required" 才会触发 validator 报错。
没加这个 tag，哪怕前端根本没传 username，ShouldBind 也一声不吭，Username 字段就是空字符串——这在登录、注册等关键接口里极其危险。
真正容易被忽略的是：错误类型不是 error，而是 validator.ValidationErrors，直接 fmt.Println(err) 看不出字段名，得用反射或 validator 提供的 Translate 方法才能拿到可读信息。
