shouldbindjson 不校验 content-type，需手动检查或改用 shouldbindwith；结构体字段须导出并正确设置 json tag；error 类型不统一，应类型断言区分；bindjson 自动返回 400 但响应格式简陋。
ShouldBindJSON 会静默失败，不校验 Content-Type
很多人以为 ShouldBindJSON 会自动拒绝非 application/json 请求，其实不会。它只管解析请求体字节，不管 Header。如果前端发来 application/x-www-form-urlencoded 或空 Body，ShouldBindJSON 可能返回 nil（解析空对象成功），也可能返回 err（比如 JSON 格式错误），但绝不会因为 Content-Type 不对而报错。
- 务必在绑定前手动检查：
c.GetHeader("Content-Type")是否包含application/json - 更稳妥的做法是用
c.ShouldBindWith(&req, binding.JSON)，它底层会校验 Content-Type - 如果允许多种格式（如同时支持 JSON 和表单），别混用
ShouldBindJSON和ShouldBind，否则字段覆盖逻辑难预测
结构体字段没绑定上？检查导出和 tag
Go 的反射只能访问首字母大写的导出字段，且 ShouldBindJSON 默认依赖 json tag。小写字段、没加 tag、tag 值为空或拼写错误，都会导致字段始终为零值。
- 字段必须导出：
Name string `json:"name"`✅，name string❌ - 如果 JSON key 是
user_id，结构体字段应写：UserID int `json:"user_id"` - 想让字段可选且不强制校验空值，加
omitempty：Age int `json:"age,omitempty"` - 注意：Gin 默认使用
mapstructure解析，不识别json:",string"这类字符串转数字的 hack，要转换得自己处理
绑定失败时 error 类型不统一，别直接判 nil
ShouldBindJSON 返回的 error 不是单一类型，可能是 validator.ValidationErrors（开启校验时）、json.SyntaxError、io.EOF（空 body）、甚至 binding.ErrUnknown。直接写 if err != nil 没问题，但想区分原因就得类型断言。
- 校验失败（如
binding:"required"）：用errors.As(err, &ve)捕获validator.ValidationErrors - JSON 语法错误：用
errors.Is(err, &json.SyntaxError{})判断（注意是地址比较） - 空请求体：常见
io.EOF或http.ErrBodyReadAfterClose，建议统一返回 400 而不是 500 - 别用
err.Error()包含敏感字段名，避免信息泄露
ShouldBindJSON 和 BindJSON 的关键区别在 panic 处理
ShouldBindJSON 出错只返回 error，由你决定怎么处理；BindJSON 内部调用 ShouldBindJSON，但一旦出错就自动调 c.AbortWithError(400, err) 并 return。它省代码，但失去控制权。
- 需要自定义错误响应（如统一加 traceID、转成特定 JSON 格式）：用
ShouldBindJSON - 只是简单接口、不想写重复错误处理：用
BindJSON更干净 - 注意：
BindJSON的 400 响应体是纯文本（err.Error()），不带 status 字段，前端不好解析 - 两者都**不会**自动读取多次 Body —— 如果之前调过
c.Request.Body，再调绑定会失败，需用c.Request.Body = ioutil.NopCloser(...)恢复（但不推荐）
最常被忽略的是 Body 只能读一次这个限制，以及 Content-Type 不校验带来的测试盲区。线上遇到“参数明明传了却为空”，八成在这两处。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
