shouldbindjson更优：需传结构体指针、依赖json tag映射、支持binding校验，错误需手动处理；bindjson则自动返回400且无法自定义响应。
直接用 c.ShouldBindJSON(&struct)，别用 c.BindJSON() —— 前者可控错误处理，后者会静默返回 400。
ShouldBindJSON 的基本用法和必须传指针
它只接受结构体指针，传值会导致绑定成功但字段全为空。错误类型通常是 json: cannot unmarshal string into Go value of type int 或 invalid memory address or nil pointer dereference（后者多因忘了取地址）。
- 必须写成
c.ShouldBindJSON(&req)，不能是c.ShouldBindJSON(req) - 结构体字段必须有
json:"xxx"标签，否则 JSON 字段根本不会映射过去 - 如果请求体为空或不是合法 JSON，会返回
io.EOF或json.SyntaxError类错误
binding 标签校验不生效的常见原因
加了 binding:"required" 却没报错？大概率是字段类型不匹配导致校验被跳过。比如字符串字段填了 null，Go 解析为 ""，而 binding:"required" 对空字符串默认认为“已提供”，不触发失败。
-
string类型的required校验对""不报错；要用binding:"required,gt=0"或自定义验证器 -
int字段收到"abc"会先解析失败，校验不执行；收到null则解析为0，min=1才会起作用 - 嵌套结构体需确保外层字段非空，否则内层
binding不触发（Gin 默认不递归校验 nil 嵌套）
ShouldBindJSON 和 ShouldBind 的自动识别差异
c.ShouldBind() 会根据 Content-Type 自动选绑定器，但对 JSON 请求，它要求 Content-Type: application/json 严格匹配。而 c.ShouldBindJSON() 强制走 JSON 解析，不看 header。
- 前端发 JSON 但漏设
Content-Type→ShouldBind()可能误判为 form，绑定失败；ShouldBindJSON()仍可用 - 想同时支持 JSON 和 form 提交？别混用，拆成两个路由，或统一用
ShouldBind()+ 多标签结构体（json:"x" form:"x"） -
ShouldBindJSON()性能略高——跳过 content-type 判断，直奔json.Unmarshal
结构体字段名大小写与 JSON key 匹配陷阱
Go 结构体字段必须导出（首字母大写），否则 json.Unmarshal 无法赋值，字段永远是零值。这是最隐蔽也最高频的问题。
- 写成
Name string `json:"name"`✅；写成name string `json:"name"`❌（绑定后name永远是""） - 如果 JSON key 是
user_name，结构体字段得是UserName string `json:"user_name"`，不能靠小写自动转换 - 别依赖 IDE 自动生成结构体——复制 JSON 后粘贴生成的字段名常是小写，必须手动改首字母
真正麻烦的不是语法，而是字段导出状态、空字符串语义、content-type 与绑定器的耦合这三处——它们不出错则已，一出就是 5 分钟找不到原因的静默失败。
