c.ShouldBind出错后不自动走统一错误格式，因其默认仅记录错误而不终止中间件链或返回响应体；需手动调用c.Error()并配合末尾统一错误中间件，用c.AbortWithStatusJSON()输出标准错误响应。

为什么 c.ShouldBind 出错后不自动走统一错误格式

c.ShouldBind 或 c.ShouldBindJSON 失败时，Gin 默认调用 c.AbortWithError，把错误塞进 c.Errors，但**不会终止中间件链，也不会返回响应体**。前端收到的可能是空 200，或者被后续 handler 覆盖成 200 + 成功数据——根本看不到错误。

• 这是 Gin 的设计：绑定失败只是“记录错误”，不是“触发响应”
• 默认 recovery 中间件只捕获 panic，对这类逻辑错误完全无感
• 如果你在 handler 里写了 c.ShouldBindJSON(&req) 后没手动处理 err，就等于什么都没返回

如何让 validator 错误也进统一错误中间件

关键不是改 validator，而是确保所有校验失败都走 c.Error()（不是 c.JSON），再由末尾中间件统一消费。

• handler 内不要写 c.JSON(400, ...)，统一改成 c.Error(errors.New("invalid param"))
• 如果用了自定义 validator（如 go-playground/validator），在 ShouldBind 后加判断：

  if err := c.ShouldBindJSON(&req); err != nil {
      c.Error(err) // 让它进 c.Errors
      return
  }

• 中间件里用 c.Errors.Last() 取最新错误，避免被日志中间件等提前消费掉

c.Error() 和 c.AbortWithError() 到底该选哪个

两者语义完全不同，混用会导致状态码和响应体错乱。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• c.Error()：仅向 c.Errors 追加错误，**不中断执行**，适合“记录但继续流程”（比如鉴权失败记日志但允许后续中间件做降级）
• c.AbortWithError(statusCode, err)：立即终止 handler 链，并**写入响应体**，但它的响应格式是原始字符串，不走你的 JSON 模板
• 真正要统一格式，必须用 c.Error() + 自定义中间件末尾调用 c.AbortWithStatusJSON()，不能依赖 c.AbortWithError()

统一中间件必须放在 Use 链的最末尾

顺序错了，响应就会被覆盖或 panic。

立即学习“go语言免费学习笔记（深入）”；

• 正确顺序：router.Use(CustomRecovery(), AuthMiddleware(), UnifiedErrorMiddleware())
• UnifiedErrorMiddleware 必须在最后，否则前面中间件可能已调用 c.JSON 或 c.AbortWithStatusJSON，再写就会报 header already written
• 中间件内必须用 c.AbortWithStatusJSON()，不能用 c.JSON() + c.Abort()，前者确保链路终止且 content-type 正确
• 检查 c.Errors 前先调用 c.Next()，否则 handler 还没跑，c.Errors 肯定为空

实际最难绷的是错误类型判断——别用 err.Error() == "xxx" 字符串匹配，得用 errors.Is(err, ErrInvalidParam) 配合自定义 error 类型，不然一升级 validator 版本，错误消息微调，整个判断就失效。