go中panic仅用于不可恢复的程序错误，业务错误须用error返回；recover必须在defer中调用且仅对同goroutine有效；gin等框架需自定义recovery中间件，按*apperror→error→default顺序类型断言并返回对应http状态码。
Go 里没有传统 try-catch，panic 和 recover 怎么用才不翻车
Go 不支持异常（exception），所谓“自定义异常”本质是封装错误值或触发 panic 后手动恢复。但直接滥用 panic 会导致程序崩溃不可控，尤其在 HTTP 框架中——比如 Gin 或 Echo，panic 若没被中间件捕获，会直接返回 500 且堆栈泄露。
关键原则：panic 只用于真正不可恢复的程序错误（如配置加载失败、DB 连接池初始化失败），业务错误一律用 error 返回；框架层统一用 recover 拦截顶层 panic，并转为结构化响应。
-
recover必须在defer中调用，且只能在当前 goroutine 生效；跨 goroutine 的 panic 无法 recover - Gin 默认 panic 中间件只捕获 handler 内 panic，不捕获 middleware 自身 panic，需确保中间件也包裹
defer/recover - 不要在 defer 里直接 log.Fatal 或 os.Exit，这会让整个进程退出，而不是仅终止当前请求
Gin 框架中注册全局错误处理器：覆盖默认 recovery 中间件
Gin 自带 gin.Recovery()，但它只打印堆栈、返回 500，不区分错误类型，也不支持自定义状态码或响应结构。要实现“自定义异常优先级”，得替换它。
实操建议：写一个兼容原逻辑但可扩展的 recovery 中间件，核心是判断 recover() 返回值类型：
func CustomRecovery() gin.HandlerFunc {
return func(c *gin.Context) {
defer func() {
if err := recover(); err != nil {
var statusCode int
var msg string
switch e := err.(type) {
case *AppError: // 自定义业务异常，如 e.Code == 401 → 401 响应
statusCode = e.Code
msg = e.Message
case error:
statusCode = http.StatusInternalServerError
msg = "Internal server error"
default:
statusCode = http.StatusInternalServerError
msg = fmt.Sprintf("Unknown error: %v", e)
}
c.AbortWithStatusJSON(statusCode, gin.H{"error": msg})
}
}()
c.Next()
}
}
- 必须在
c.Next()前注册defer，否则 panic 发生时 c 已结束生命周期 - 类型断言顺序很重要：先匹配具体自定义错误类型（如
*AppError），再 fallback 到error，最后兜底default，否则error会提前匹配所有接口值 - 别忘了调用
c.Abort()或c.AbortWithStatusJSON()，否则后续 handler 仍会执行
定义分层错误类型：AppError vs ValidationError vs NotFoundError
所谓“捕获优先级”，实际是错误类型的处理顺序。Go 里靠类型断言和 if-else 链实现，不是语法级优先级。推荐按语义建模，而非堆砌错误码：
type AppError struct {
Code int
Message string
Cause error
}
func NewValidationError(msg string) *AppError {
return &AppError{Code: http.StatusBadRequest, Message: msg}
}
func NewNotFoundError(msg string) *AppError {
return &AppError{Code: http.StatusNotFound, Message: msg}
}
- 所有自定义错误都实现
error接口（即有Error() string方法），方便上游直接返回或包装 - 用字段
Cause保留原始 error，便于日志追踪和 debug，但 JSON 响应时不应暴露内部细节 - 避免用字符串匹配错误信息来判断类型——不可靠、难维护、影响性能
HTTP handler 中主动触发自定义错误：别用 panic 处理业务逻辑
常见误区：在 handler 里写 if user == nil { panic(NewNotFoundError("user not found")) }。这会绕过正常错误流，让 recover 中间件被迫承担本该由 if-else 完成的分支逻辑。
正确做法是显式返回错误，并由上层统一处理：
func GetUser(c *gin.Context) {
id := c.Param("id")
user, err := userService.FindByID(id)
if err != nil {
if errors.Is(err, ErrUserNotFound) {
c.JSON(http.StatusNotFound, gin.H{"error": "user not found"})
return
}
c.JSON(http.StatusInternalServerError, gin.H{"error": "internal error"})
return
}
c.JSON(http.StatusOK, user)
}
- 只有当错误无法在当前 handler 合理处理（比如数据库连接突然断开、配置项缺失）时，才考虑
panic并交由 recovery 中间件兜底 - 使用
errors.Is或errors.As判断错误类型，比字符串比较更安全、支持包装链 - 如果项目规模大，可引入错误码映射表，但别把 HTTP 状态码硬编码进每个 handler，而是收口到 error 类型的
StatusCode()方法中
最易被忽略的一点：recover 中间件对异步 goroutine 无效。比如你在 handler 里启了个 goroutine 做耗时任务，它 panic 了，主请求流程完全感知不到——这种场景必须在 goroutine 内部自己做 defer/recover，并把错误通过 channel 或回调传出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
