c.Error() 不会返回 HTTP 响应，因为它仅将错误追加到 c.Errors 切片中而不终止执行或写响应体；调用后若未手动调用 c.AbortWithStatusJSON 或 c.JSON，客户端可能收到空的 200 OK。
为什么 c.Error() 不会返回 HTTP 响应
c.Error() 只是把错误追加到 c.Errors 切片里，不终止执行，也不写响应体。你调了 c.Error(fmt.Errorf("user not found")) 之后如果没手动 c.AbortWithStatusJSON 或 c.JSON，客户端收不到任何内容，甚至可能拿到空的 200 OK。
常见错误现象：接口返回空白、状态码是 200 但 body 为空、前端一直 pending。
-
c.Error()是为中间件链路追踪设计的，比如日志、监控中间件读取c.Errors做记录 - 真正能发响应的只有
c.AbortWithStatusJSON、c.JSON + c.Abort()、c.AbortWithError - 别在 handler 里混用
c.Error()和c.JSON()，容易漏掉c.Abort()导致重复写 body
统一错误中间件必须放在 Use 链末尾
中间件执行顺序决定响应是否被覆盖。如果你把统一错误处理中间件写在 gin.Logger() 或鉴权中间件前面，后者可能已经调用了 c.JSON，再渲染就冲突了。
正确姿势是把它作为最后一个 router.Use()：
router.Use(middleware.Logger()) router.Use(middleware.Auth()) router.Use(middleware.UnifiedError()) // 必须放最后
-
c.Next()后检查c.Errors，取c.Errors.Last()—— 因为 Gin 按顺序 append，最新错误通常是业务层抛出的 - 不要用
for range c.Errors全部渲染，一个请求只该有一个错误响应 - 若 handler 中已调用
c.AbortWithStatusJSON，c.Errors仍可能非空，但响应已发出，此时应跳过渲染（可通过c.IsAborted()判断）
validator 错误怎么进统一格式
c.ShouldBind() 失败时，Gin 默认调用 c.AbortWithError(400, err)，会把错误塞进 c.Errors，但不会自动返回 JSON —— 所以它天然适配统一错误中间件，前提是中间件没被提前 abort。
但要注意：c.ShouldBindJSON 报错后，handler 剩余逻辑还会继续执行，可能引发 panic 或二次响应。
- 推荐写法：显式判断绑定结果，出错立刻
c.Abort() - 或者直接依赖统一中间件兜底，但得确保中间件在链尾且未被覆盖
- 自定义 validator tag（如
binding:"required,email"）的错误信息会进err，可解析err.(error).Error()提取，或用第三方包如go-playground/validator获取字段级详情
panic 和逻辑错误要分开兜底
gin.Recovery() 只捕获主 goroutine 的 panic，对 go func() { ... }() 里的 panic 完全无效；而 c.Error() 又不处理 panic。两者覆盖场景不同，必须双管齐下。
- 主流程 panic → 用自定义
Recovery()中间件，记录 stacktrace 并返回脱敏的 500 - 业务逻辑错误（参数错、查不到、权限不足）→ 用
c.Error()+ 统一中间件 - 异步 goroutine → 必须自己 defer recover，且不能操作
c（context 已结束），只能打日志或发告警 - HTTP 状态码和业务码要分离：401/403 返回带提示的 JSON；500 必须隐藏堆栈、路径、变量名等敏感信息
最易被忽略的一点：统一中间件无法替代 c.AbortWithError 在关键校验点的即时响应 —— 比如 token 解析失败，必须立刻中断，不能等到中间件末尾才处理，否则可能泄露数据或执行多余 DB 查询。
