默认的gin.Recovery()只捕获主goroutine的panic，异步goroutine中的panic需手动recover；c.Error()不中断执行，c.AbortWithError()才终止后续handler并写入响应。
为什么 recovery 中间件没拦住 panic？
因为默认的 gin.Recovery() 只捕获当前 goroutine 的 panic，而你如果在异步 goroutine（比如 go func() {}()）里触发 panic，它就完全看不到。这不是 bug，是设计使然——中间件只作用于 HTTP 请求生命周期内的主 goroutine。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 绝对避免在
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 对不上。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 需要立刻返回错误响应时，无条件用
c.AbortWithError(statusCode, err)，例如参数校验失败：if id <= 0 { c.AbortWithError(400, errors.New("invalid id")) return // 这个 return 其实可省，AbortWithError 已终止流程 } -
c.Error()仅适合收集上下文错误供后续中间件（如日志、监控）消费，比如在鉴权中间件里记录c.Error(authErr)，但不阻断流程 - 注意
c.AbortWithError第二个参数必须是error类型，传字符串会 panic
统一错误响应结构，但 401 和 500 要分开发？
要分。401/403 是客户端问题，响应体可以带提示；500 是服务端 panic 或未预期错误，响应体必须脱敏，否则可能泄露路径、变量名甚至数据库字段。Gin 默认 recovery 中间件返回的 HTML 页面在生产环境必须关掉。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 自己写 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” 这种错误信息根本没法定位。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
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 字符串里，方便后续检索
