Golang怎么用Gin错误处理中间件_Golang如何统一捕获接口错误返回规范响应【实战】-Golang-PHP中文网

默认的gin.Recovery()只捕获主goroutine的panic，异步goroutine中的panic需手动recover；c.Error()不中断执行，c.AbortWithError()才终止后续handler并写入响应。

golang怎么用gin错误处理中间件_golang如何统一捕获接口错误返回规范响应【实战】

为什么 `recovery` 中间件没拦住 panic？

因为默认的 gin.Recovery() 只捕获当前 goroutine 的 panic，而你如果在异步 goroutine（比如 go func() {}()）里触发 panic，它就完全看不到。这不是 bug，是设计使然——中间件只作用于 HTTP 请求生命周期内的主 goroutine。

实操建议：

绝对避免在 go 启动的匿名函数里直接操作响应（c.JSON、c.String 等），那会引发 panic 且无法被捕获

真要异步，用带 recover 的子 goroutine：

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("async panic: %v", r)
        }
    }()
    // 业务逻辑
}()

检查是否手动调用了 panic() 且没被 gin.Recovery() 包裹——比如在中间件链之外、或在 router.NoRoute() 之后注册的 handler 里

`c.AbortWithError` 和 `c.Error` 到底该用哪个？

c.Error() 只是把错误塞进 Gin 的 error slice，不中断执行；c.AbortWithError() 才真正终止后续 handler 并写入响应。很多人误以为调了 c.Error() 就等于返回了，结果后面又执行了 c.JSON(200, ...)，导致 HTTP 状态码和 body 对不上。

实操建议：

需要立刻返回错误响应时，无条件用 c.AbortWithError(statusCode, err)，例如参数校验失败：
```
if id 
```
c.Error() 仅适合收集上下文错误供后续中间件（如日志、监控）消费，比如在鉴权中间件里记录 c.Error(authErr)，但不阻断流程
注意 c.AbortWithError 第二个参数必须是 error 类型，传字符串会 panic

统一错误响应结构，但 `401` 和 `500` 要分开发？

要分。401/403 是客户端问题，响应体可以带提示；500 是服务端 panic 或未预期错误，响应体必须脱敏，否则可能泄露路径、变量名甚至数据库字段。Gin 默认 recovery 中间件返回的 HTML 页面在生产环境必须关掉。

Golang Uber Dig

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

下载

实操建议：

自己写 recovery 替代默认的：

func CustomRecovery() gin.HandlerFunc {
    return func(c *gin.Context) {
        defer func() {
            if err := recover(); err != nil {
                c.AbortWithStatusJSON(500, map[string]interface{}{
                    "code": 500,
                    "msg":  "Internal server error",
                    "data": nil,
                })
            }
        }()
        c.Next()
    }
}

所有业务错误走 c.AbortWithError，并在全局 error handler 里格式化：

router.Use(func(c *gin.Context) {
    c.Next()
    if len(c.Errors) > 0 {
        lastErr := c.Errors.Last()
        switch lastErr.Err.(type) {
        case *biz.ValidationError:
            c.AbortWithStatusJSON(400, Response{Code: 400, Msg: lastErr.Error()})
        default:
            c.AbortWithStatusJSON(500, Response{Code: 500, Msg: "Server error"})
        }
    }
})

确保 gin.SetMode(gin.ReleaseMode) 开启，否则 recovery 会返回堆栈

中间件里怎么拿到原始 panic 堆栈？

Gin 的 recovery 默认只记录日志，不暴露堆栈。但线上排查时，光有 “interface conversion: interface {} is int, not string” 这种错误信息根本没法定位。

实操建议：

用 debug.Stack() 拿完整堆栈，但别直接返回给前端：

stack := debug.Stack()
log.Printf("Panic recovered: %s\n%s", err, stack)

堆栈太长容易打爆日志，建议截取前 2048 字节：

stack := debug.Stack()
if len(stack) > 2048 {
    stack = stack[:2048]
}

如果用的是 zap 或 zerolog，把 stack 作为字段写进日志，别拼进 message 字符串里，方便后续检索

Gin 错误处理真正的复杂点不在怎么写中间件，而在于「错误来源」本身混杂：HTTP 解析失败、绑定失败、业务校验失败、DB 超时、第三方 API 返回异常……每种错误的语义、重试策略、可观测性要求都不同。统一响应只是表层，背后得靠错误类型区分 + 上下文透传 + 日志分级，否则越统一封装，越难 debug。