Golang怎么用Gin实现panic恢复中间件_Golang如何捕获接口异常返回友好错误信息【避坑】-Golang-PHP中文网

panic恢复中间件必须用defer包裹recover()，且仅在gin handler的defer中生效；需调用c.abortwithstatusjson()终止流程并安全返回错误，避免敏感信息泄露和路由误捕获。

golang怎么用gin实现panic恢复中间件_golang如何捕获接口异常返回友好错误信息【避坑】

panic 恢复中间件必须用 `recover()` 且只能在 defer 中生效

Go 的 recover() 不是 try-catch，它只在 defer 函数里、且当前 goroutine 发生 panic 后才有效。Gin 的 handler 是在独立 goroutine（或 Gin 自己的请求协程）中执行的，所以恢复逻辑必须写在 handler 执行路径上的 defer 里——中间件就是最自然的位置。

常见错误是把 recover() 写在普通函数里，或者没包在 defer 中，结果 panic 依然向上冒泡，服务直接 500 或 crash。

必须用 defer func() { if r := recover(); r != nil { ... } }() 包裹
不能只写 recover() 而不接 defer，那等于没写
Gin 的 c.Next() 之后才可能 panic，所以 defer 要放在 c.Next() 前面，但闭包里要等 panic 发生后才执行

func Recovery() gin.HandlerFunc {
    return func(c *gin.Context) {
        defer func() {
            if err := recover(); err != nil {
                // 这里才能捕获到 panic
                c.AbortWithStatusJSON(500, gin.H{"error": "internal server error"})
            }
        }()
        c.Next()
    }
}

不要直接返回 panic 值，要区分类型并过滤敏感信息

panic 可能是 string、error、自定义 struct，甚至 nil。直接 fmt.Sprintf("%v", err) 返回给前端，容易泄露文件路径、变量名、数据库连接串等——尤其在生产环境开启 debug 模式时极危险。

更糟的是，有些 panic 来自第三方库（比如 json 解析失败、空指针解引用），它们的底层值可能含内部状态，不该透出。

永远用 fmt.Sprint(err) 或显式类型断言，避免 %+v 泄露堆栈
对已知错误类型（如 *json.UnmarshalTypeError）做特判，转成用户友好的提示
生产环境强制忽略 panic 值内容，统一返回泛化错误，例如 "something went wrong"
开发环境可额外记录完整 panic + 堆栈到日志，但绝不返回给 HTTP 响应

Gin 的 `c.Abort()` 和 `c.AbortWithStatusJSON()` 行为差异很关键

panic 恢复后，请求流程不能继续往下走，否则可能重复写响应体、触发多次 DB 操作，甚至 panic 二次发生。这时候必须中断 Gin 的 middleware 链，但方式选错会导致 500 不返回、响应体为空、或 Content-Type 错乱。

Golang Uber Dig

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

下载

c.Abort() 只是跳过后续中间件，不终止响应；而 c.AbortWithStatusJSON() 会设置状态码、Content-Type，并写入 JSON，同时调用 c.Abort()。漏掉这个，就只剩个空 200 或上层默认 500。

恢复 panic 后必须调用 c.AbortWithStatusJSON() 或至少 c.AbortWithError()，不能只 log 就完事
别在恢复逻辑里调 c.JSON() + c.Abort() 分两步，有竞态风险：万一其他中间件也写了响应头，JSON 会失败
如果需要自定义错误结构（比如带 code 字段），用 c.AbortWithStatusJSON(500, yourErrStruct)，别手写 http.Error

全局 recovery 中间件要避开健康检查和静态资源路由

加在 router.Use(Recovery()) 确实省事，但会导致 /healthz 或 /static/xxx.js 出错时也走 recovery，掩盖真实问题。比如静态文件 404 被误当成 panic 处理，返回 500 而非 404，前端监控全乱。

更隐蔽的问题是：某些中间件（如 JWT 验证）提前 abort 并返回 401，但 recovery 仍会执行——因为 c.Next() 已调用，只是后续 handler 没跑。这会让 recovery 日志里刷满“假 panic”。

把 recovery 放在业务路由组里，而不是全局：api := r.Group("/api"); api.Use(Recovery()); api.GET(...)
健康检查路由（如 /health）单独挂，不走 recovery
静态文件用 r.Static() 时，Gin 内部已处理 404，不会 panic，无需 recovery 干预
如果用了 gin.Error 主动 abort，不属于 panic，recovery 不该也不必捕获它

真正难搞的是嵌套 panic：比如 handler 里 defer 捕获了 panic，又在 defer 里 panic 了。这种得靠日志上下文和 panic 嵌套深度判断，不是加一层 middleware 就能兜住的。