shouldbindjson 不自动返回400错误，仅返回error供自主处理；bindjson则自动调用abortwitherror设400状态码并写死响应头为text/plain，后续修改状态码会触发警告。
c.ShouldBindJSON() 是最常用且推荐的 JSON 绑定方式
它会读取 Request.Body，按 JSON 格式反序列化到结构体，并支持字段级验证（如 binding:"required"）。和 c.BindJSON() 不同，它不自动返回 400 错误，而是把错误交给你处理，更适合统一错误响应逻辑。
- 必须确保结构体字段有
json标签，否则字段值始终为空 —— 比如Username string `json:"username"`，不能只写form:"username" - 如果请求体不是合法 JSON（比如少个逗号、多引号），
c.ShouldBindJSON()会返回invalid character ...类错误，而不是验证失败 - 重复调用
c.ShouldBindJSON()会失败：因为Request.Body只能读一次，第二次读就是空的 —— 需要用c.ShouldBindBodyWith()缓存 body
动态解析 JSON：用 map[string]interface{} 避免写 struct
当接口接收的 JSON 结构不固定（比如前端传任意 key、嵌套层级深或字段名带变量），硬写 struct 成本高且易错。这时直接解析为 map[string]interface{} 更灵活。
- 用
c.BindJSON(&m)或json.Unmarshal(c.Request.Body, &m)都可以，但注意c.BindJSON()也会消耗Body - 嵌套数组需手动类型断言：
batCodes := m["batCodes"].([]interface{})，每个元素再转成map[string]interface{}，然后取["batCode"].(string)等 - 数字默认解析为
float64（JSON 规范无 int/float 区分），所以position这类整型字段要显式转：int(pos.(float64))
结构体标签混用 json/form/uri 时的绑定行为
Gin 的 c.ShouldBind() 会根据 Content-Type 自动选绑定器，但结构体标签必须覆盖对应来源 —— 否则字段无法填充。
- 如果同时支持 JSON 和表单提交，结构体字段得同时带
json:"xxx"和form:"xxx"，否则表单提交时该字段为空 -
uri:"xxx"只在c.ShouldBindUri()中生效，和 JSON 解析无关；别指望json标签能从 URL 路径里取值 - 标签里写
binding:"-"表示跳过验证，但字段仍会被赋值；写binding:"-"+ 不写json标签，则该字段完全不会被 JSON 解析填充
ShouldBindJSON 失败却没报错？检查 Content-Type 和 Body 是否被提前读取
常见现象：明明 POST 了 JSON，c.ShouldBindJSON(&v) 却返回 nil 错误，但 v 里全是零值。根本原因往往不是代码逻辑，而是请求头或中间件干扰。
- 前端必须发
Content-Type: application/json，否则 Gin 默认走 form 绑定器，忽略json标签 - 如果有中间件（比如日志、鉴权）调用了
c.Request.Body，body 就被读空了 —— 后续ShouldBindJSON必然失败 - 调试时可用
io.ReadAll(c.Request.Body)打印原始内容，但记得用c.Request.Body = io.NopCloser(bytes.NewBuffer(...))恢复，否则后续绑定仍失败
Content-Type 不匹配导致绑定器选错 —— 这俩问题不看请求头和中间件链，光盯结构体是查不到的。
