recover()必须在defer中调用，因为它是栈展开拦截器而非监听器，仅在panic发生后、当前goroutine栈未完全展开前，于defer函数内直接调用才有效；普通调用恒返回nil。
为什么 recover() 必须在 defer 中调用
因为 Go 的 panic 只能在当前 goroutine 的 defer 函数中被捕获，且必须在 panic 发生后、栈完全展开前执行。如果写成普通函数调用，recover() 永远返回 nil——它不是“监听器”，而是“栈展开拦截器”。
常见错误是把 recover() 放在中间件主逻辑里，比如：
func PanicMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// ❌ 错误：这里 recover() 无效
if r := recover(); r != nil {
http.Error(w, "internal error", http.StatusInternalServerError)
}
next.ServeHTTP(w, r)
})
}
正确写法必须包裹在 defer 内部，并确保它在 panic 触发点之后仍处于调用栈上：
func PanicMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
// 处理 panic
http.Error(w, "internal error", http.StatusInternalServerError)
}
}()
next.ServeHTTP(w, r)
})
}
如何区分 panic 类型并返回不同 HTTP 状态码
直接用 http.Error() 统一返回 500 是粗暴的。很多 panic 其实是业务可预期的（比如 panic("not found")），应该映射为 404；而空指针或类型断言失败才是真正的 500。
立即学习“go语言免费学习笔记（深入）”；
推荐用自定义 panic 值 + 类型断言来分类处理：
- 用字符串 panic 时，检查是否以
"404:"或"400:"开头，提取状态码和消息 - 定义带状态码的 error 类型（如
type HTTPError struct{ Code int; Msg string }），panic(&HTTPError{Code: 401, Msg: "unauthorized"}) - 避免 panic
nil、int、struct{}等无法判断意图的值，它们会让 recover 后的分支逻辑失控
示例中对 panic 值做类型判断：
if r := recover(); r != nil {
switch x := r.(type) {
case string:
if strings.HasPrefix(x, "404:") {
http.Error(w, x[4:], http.StatusNotFound)
} else {
http.Error(w, x, http.StatusInternalServerError)
}
case *HTTPError:
http.Error(w, x.Msg, x.Code)
default:
http.Error(w, "internal error", http.StatusInternalServerError)
}
}
Gin / Echo 等框架中的 panic 恢复机制差异
这些框架默认已注册 panic 恢复中间件，但行为不一致：
-
Gin的gin.Recovery()默认只打印日志，不返回 JSON；若启用了gin.DebugMode，还会暴露堆栈，生产环境必须关闭 -
Echo的echo.HTTPErrorHandler不处理 panic，需手动注册e.Use(middleware.Recover())，且它的默认响应是纯文本，不是 JSON - 自研框架或 net/http 直接使用时，必须自己写
defer recover()，没有“默认兜底”
关键点：不要假设框架帮你做了“标准错误响应”。检查你用的中间件是否真的设置了 Content-Type: application/json 和结构化 body。例如 Gin 默认 recovery 返回的是 HTML 片段，要改成 JSON 需重写：
gin.SetMode(gin.ReleaseMode)
r.Use(gin.RecoveryWithWriter(customWriter, func(c *gin.Context, err interface{}) {
c.JSON(http.StatusInternalServerError, map[string]string{"error": "internal error"})
}))
recover 后的 response.WriteHeader 调用时机陷阱
一旦 next.ServeHTTP() 已经写入部分响应（比如 header 已发、甚至写了部分 body），再在 recover() 里调用 http.Error() 或 c.JSON() 会 panic：“http: multiple response.WriteHeader calls”。这不是 recover 没生效，而是响应流已被污染。
解决方案只有两个：
- 用 ResponseWriter 包装器（如
httptest.ResponseRecorder或自定义responseWriter）先缓存输出，等 recover 完再决定发什么 - 严格保证中间件顺序：panic 恢复中间件必须是最外层，所有可能 panic 的逻辑（如 JSON 解析、DB 查询）都在它内侧，且不能提前写响应
最容易被忽略的是日志中间件——如果它在 panic 恢复之前，并且尝试读取请求 body（触发解析 panic），又或者在 panic 后还试图写日志到已关闭的连接，就会连锁出错。
