shouldbindjson不会静默跳过校验，但仅当字段显式声明binding标签（如required、email）时才触发validator校验；无binding标签的字段无论是否为空或非法均不校验，直接以零值绑定。
ShouldBindJSON 会静默跳过字段校验？
不会，但前提是结构体字段必须显式写 binding 标签。Gin 完全不看 json 标签是否匹配、也不自动对未声明 binding 的字段做任何校验——哪怕字段名和请求体完全一致，没写 binding:"required" 就等于“这个字段我不验”。
常见错误包括：
- 误把
json:"email" validate:"email"当成有效校验（validate标签 Gin 不识别） - 写了
json:"id"但漏掉binding，结果空字符串或非法值直接进业务逻辑，后续 panic - 嵌套结构体里忘了加
dive，导致子字段校验被跳过（比如Address struct{ City string `binding:"required"` }必须写成Address Address `binding:"required,dive"`）
为什么 c.Error() 不触发响应，而 c.AbortWithStatusJSON() 才行
c.Error() 只是把错误塞进 c.Errors 队列，它不写响应体、不设状态码、也不终止中间件链——它纯粹是个信号机制。真正要返回 JSON 错误，必须在某个中间件里调用 c.AbortWithStatusJSON()。
典型陷阱：
- 在 handler 里调用
c.Error(ErrInvalidParam)后没做任何处理，请求继续往下走，最后可能返回 200 成功响应 - 多个中间件都尝试
c.AbortWithStatusJSON()，第二次调用会 panic：「header already written」 - 把
c.JSON()和c.Abort()拆开用，漏掉c.Abort()导致响应被后续中间件覆盖
统一校验错误中间件怎么写才不漏 case
一个可靠的校验错误中间件必须同时捕获两类失败：绑定解析失败（如 string → int64 类型错）、以及 validator 规则失败（如 min=6 不满足）。这两类错误都会让 c.ShouldBindJSON() 返回非 nil err，但只有 validator 错误能转成 validator.ValidationErrors 类型。
实操建议：
- 中间件放在
router.Use()链中 recovery 之后、路由注册之前 - 不要只依赖
errors.Is(err, ...)，先判断err是否为validator.ValidationErrors，再用err.(validator.ValidationErrors).Translate(trans)提取中文提示 - 对非 validator 错误（如 JSON 解析失败、类型转换失败），归为
ErrInvalidParam并返回 400 - 确保该中间件只执行一次响应，且用
c.AbortWithStatusJSON()终止链路
HTTP 状态码和业务 code 必须分开设计
前端需要靠 HTTP 状态码做网络层判断（比如 401 跳登录页、503 自动重试），而业务逻辑错误（参数错、用户不存在、库存不足）必须用独立的 code 字段区分——混用会导致网关或监控系统误判。
例如：
- 参数校验失败 → HTTP 400 +
{"code": 1001, "msg": "用户名不能为空"} - 数据库查不到用户 → HTTP 404 +
{"code": 4001, "msg": "用户不存在"} - 服务内部 panic → HTTP 500 +
{"code": 5000, "msg": "服务器内部错误"}
最易忽略的是：错误码不能散落在各 handler 里硬编码，必须集中定义为常量，否则后期排查、文档、前端适配全乱套。
