gin.default() 的 panic 处理不能直接用于生产，因其 recovery 中间件仅向 stderr 打印堆栈并返回空白 500 响应，不走 json 错误格式逻辑，且暴露敏感信息、无法联动监控或熔断；必须改用 gin.new() 并注册自定义 customrecovery 中间件。
为什么 gin.Default() 的 panic 处理不能直接用于生产
因为 gin.Default() 自带的 Recovery() 中间件只向 stderr 打印堆栈，然后调用 c.AbortWithStatus(500) 返回空白响应体——它不走你写的 JSON 错误格式逻辑，也不触发 c.AbortWithStatusJSON()，前端收不到 {"code":500,"msg":"..."} 这类结构化错误。
更关键的是：它默认会把 panic 原始信息（比如 panic: runtime error: invalid memory address or nil pointer dereference）直接暴露在日志里，若调试模式开启，甚至可能泄露路径、变量名等敏感内容；也无法联动熔断、上报监控或写结构化日志。
- 禁用默认 recovery 是必须的第一步：改用
gin.New()初始化引擎 - 必须手动注册自定义 recovery 中间件，且顺序要在所有业务中间件之前
-
c.AbortWithStatusJSON()是唯一安全写响应的方式；c.JSON() + c.Abort()有风险，后续中间件可能继续执行并重复写响应
如何手写一个返回 JSON 的 CustomRecovery 中间件
核心是 defer + recover() 捕获 panic，再统一构造响应。注意 panic 类型可能是 string、error 或其他类型，不能直接 fmt.Sprintf("%v", err) 输出，否则生产环境会脱敏失败或 panic 二次崩溃。
下面是最简可用版本（已做类型安全兜底）：
func CustomRecovery() gin.HandlerFunc {
return func(c *gin.Context) {
defer func() {
if err := recover(); err != nil {
// 统一脱敏，避免类型断言失败
errMsg := "internal server error"
c.AbortWithStatusJSON(500, gin.H{
"code": 500,
"msg": errMsg,
"data": nil,
})
}
}()
c.Next()
}
}
- 务必在
recover()后立即调用c.AbortWithStatusJSON()，它内部已含c.Abort()并强制终止响应流程 - 不要尝试在 recover 后调用
c.Next()或继续业务逻辑——此时 handler 已处于不可恢复状态 - 若需记录堆栈，用
debug.Stack()，但生产环境禁止将堆栈塞进响应体；开发环境可加"stack": string(debug.Stack())字段作调试用
中间件链中 panic 的捕获范围限制
自定义 CustomRecovery() 只能捕获「当前 goroutine」内、在 c.Next() 调用链中发生的 panic。Gin 的 handler 是单 goroutine 执行，所以对路由函数和同步中间件有效；但它无法捕获以下两类 panic：
- 你在中间件或 handler 里显式启的 goroutine（如
go func() { ... panic(...) }()），这类 panic 会直接杀死整个进程 - 某些第三方库或底层调用（如数据库驱动、HTTP 客户端）抛出的未被包裹的 panic，尤其当它们自己开了 goroutine 时
解决方案不是靠一层 recovery 搞定全部，而是：
- 所有显式 goroutine 必须自带
defer+recover，例如鉴权中间件Authorization()内部要独立包一层 - 避免在业务代码中使用
log.Fatal——它调用os.Exit()，绕过所有 defer 和 recover，服务直接退出 - 对高危操作（如 JSON 解析、DB 查询）做前置校验，减少 panic 触发概率，比事后 recover 更可靠
与优雅退出（Graceful Shutdown）协同的关键点
频繁 panic 往往意味着服务已处于亚健康状态：内存泄漏、连接池耗尽、依赖服务雪崩……这时候光靠 recovery 拦住请求，只是掩盖症状。
真正该做的，是在 recover() 里加熔断标记（如 breaker.MarkFailed()）、触发告警（如 Prometheus Alertmanager）、记录结构化日志（含 traceID、panic 类型、堆栈摘要），并配合 http.Server.Shutdown() 实现自动降级或滚动重启。
容易被忽略的是：debug.Stack() 开销不小，高频 panic 场景下可能拖垮性能；建议只在首次 panic 后采样记录，或用 runtime/debug.PrintStack() 替代完整堆栈捕获。
