Go Web 中全局错误处理本质是拦截HTTP请求生命周期的错误出口，需用中间件defer+recover捕获panic并统一响应，业务错误应显式返回error而非滥用panic。
Go 本身没有 panic 捕获的顶层机制（不像 Java 的 try-catch 或 Node.js 的 uncaughtException），所谓“全局错误处理”在 Web 场景中，本质是统一拦截 HTTP 请求生命周期中的错误出口，而不是 catch 所有 panic。
用中间件包装 handler 并 recover panic
HTTP handler 中一旦 panic，默认会打印堆栈并返回 500，但无法自定义响应格式、日志或错误上报。必须在中间件里显式 recover()：
func Recovery() gin.HandlerFunc {
return func(c *gin.Context) {
defer func() {
if err := recover(); err != nil {
// 记录 panic 日志（含 stack）
log.Printf("PANIC: %+v\n%s", err, debug.Stack())
// 统一返回 JSON 错误
c.JSON(500, map[string]interface{}{
"error": "internal server error",
})
c.Abort() // 阻止后续 handler 执行
}
}()
c.Next()
}
}
- 必须用
defer+recover()，且放在c.Next()前； -
c.Abort()很关键，否则 panic 后仍可能执行后续中间件或 handler； -
debug.Stack()要手动 import"runtime/debug"； - 别直接返回
err.Error()给前端——容易泄露敏感信息。
统一 error 返回结构与 status code 映射
业务逻辑中不应直接写 c.JSON(400, ...) 或 c.String(500, ...)，而应通过封装的错误类型驱动响应：
type AppError struct {
Code int `json:"code"`
Message string `json:"message"`
}
func (e *AppError) Error() string { return e.Message }
func WriteError(c *gin.Context, err error) {
if appErr, ok := err.(*AppError); ok {
c.JSON(appErr.Code, map[string]interface{}{"error": appErr.Message})
} else {
c.JSON(500, map[string]interface{}{"error": "internal error"})
}
}
- 业务 handler 中可写
return WriteError(c, &AppError{Code: 404, Message: "not found"})； - 避免用字符串 switch 判断错误类型，优先用接口断言或错误包装（
errors.Is/errors.As）； - HTTP status code 应由错误语义决定，而非硬编码在 handler 里。
gin.Context.Value 透传请求上下文错误
当错误发生在中间件之后的深层调用（如 service → dao 层），又不想层层返回 error，可用 c.Value() + 自定义 key 临时挂载错误：
立即学习“go语言免费学习笔记（深入）”；
var ErrKey = "error"
func ValidateToken(c *gin.Context) {
token := c.GetHeader("Authorization")
if token == "" {
c.Set(ErrKey, &AppError{Code: 401, Message: "missing token"})
c.Abort()
return
}
}
func HandleUser(c *gin.Context) {
if err, ok := c.Get(ErrKey).(*AppError); ok {
WriteError(c, err)
return
}
// 正常业务逻辑
}
- 仅限简单场景；过度依赖
c.Value()会让控制流隐晦，调试困难； - 务必配合
c.Abort()，否则后续 handler 仍会执行； - 不要用字符串字面量作 key（如
"error"），易拼错，应定义为包级变量。
panic 不等于业务错误，别滥用 recover
真正该 panic 的只有程序无法继续运行的致命问题（如配置加载失败、DB 连接池初始化失败）。业务错误（参数校验失败、资源不存在）必须用显式 error 返回：
- 在 init 或 main 中 panic 是 OK 的，但在 handler 里 panic 多数是设计缺陷；
- recover 不能替代错误检查——比如
db.QueryRow().Scan()返回sql.ErrNoRows，就该用 if 判断，而不是等它触发 panic； - 大量 recover 会让性能下降（goroutine 栈扫描开销），且掩盖真实问题。
最易被忽略的一点：recover 只捕获当前 goroutine 的 panic。如果业务启了新 goroutine（如 go func() {...}()），那个 goroutine 里的 panic 不会被中间件 recover 到——必须在 goroutine 内部单独 recover。
