本文详解如何在 beego 框架中正确覆盖默认 panic 恢复逻辑，通过在控制器方法中合理使用 defer + recover 实现全局异常捕获、日志记录与告警通知，避免因 panic 导致服务中断。
本文详解如何在 beego 框架中正确覆盖默认 panic 恢复逻辑，通过在控制器方法中合理使用 defer + recover 实现全局异常捕获、日志记录与告警通知，避免因 panic 导致服务中断。
Beego 默认启用了内置的 recoverPanic 机制（对应配置项 recoverpanic = true），它会在每个 HTTP 请求的 goroutine 中自动执行 panic 恢复，并返回 500 错误页面。但若你希望完全接管 panic 处理逻辑（例如记录详细堆栈、发送告警邮件、上报监控系统），不能仅在 main() 函数中 defer 自定义 recover——因为 main() 的 defer 只作用于主线程，而 Beego 的每个请求都在独立 goroutine 中执行，panic 发生在这些子 goroutine 内，主线程的 recover 无法捕获。
✅ 正确做法是：将 defer recoverPanic() 显式添加到每个需要保护的控制器方法内部（如 Get()、Post() 等），确保 panic 在当前请求 goroutine 中被及时捕获。
以下是一个完整、可落地的自定义恢复示例：
package controllers
import (
"fmt"
"log"
"net/http"
"runtime/debug"
"strings"
"github.com/astaxie/beego"
)
// 自定义 panic 恢复函数：支持日志记录 + 邮件告警（伪代码示意）
func customRecover() {
if r := recover(); r != nil {
// 获取当前请求上下文（需结合 beego.Context 使用）
ctx := beego.BeeApp.Context
req := ctx.Request
// 记录详细错误信息
stack := debug.Stack()
errMsg := fmt.Sprintf("Panic recovered: %v\nStack:\n%s", r, stack)
log.Printf("[PANIC] %s %s | %s", req.Method, req.URL.Path, errMsg)
// ✅ 此处可集成邮件发送（如使用 net/smtp）、钉钉/企业微信机器人、Sentry 等
// sendAlertEmail(fmt.Sprintf("Beego Panic Alert: %s", r), string(stack))
// 统一返回友好错误页（或 JSON 错误响应）
ctx.ResponseWriter.WriteHeader(http.StatusInternalServerError)
ctx.ResponseWriter.Write([]byte("Service error. Admin has been notified."))
}
}
type MainController struct {
beego.Controller
}
func (c *MainController) Get() {
defer customRecover() // ✅ 关键：每个 handler 方法内单独 defer
// 模拟可能 panic 的代码（如空指针访问）
var s *string
_ = *s // 触发 panic: runtime error: invalid memory address or nil pointer dereference
}
⚠️ 重要注意事项：
- 不要关闭 recoverpanic = false 后依赖全局 recover：Beego 的 Run() 启动后，所有 HTTP 请求均由独立 goroutine 处理，main() 中的 defer 完全无效；
-
推荐封装为 Controller 基类方法：为避免重复书写 defer customRecover()，可定义基类控制器（如 BaseController），并在其 Prepare() 方法中统一注入（注意 Prepare() 是 Beego 的预处理钩子，但需确保它在 panic 前执行）：
func (c *BaseController) Prepare() { defer customRecover() c.Controller.Prepare() }然后让业务控制器继承 BaseController；
- 务必调用 debug.Stack() 获取完整堆栈：仅 recover() 返回 panic 值不够定位问题，debug.Stack() 才能提供精确的调用链；
- 生产环境慎用裸 panic：应优先通过 error 返回和校验规避 panic；自定义 recover 是兜底手段，不可替代健壮的错误处理设计。
通过以上方式，你就能在 Beego 中构建可靠、可观测、可告警的异常恢复体系，真正实现“零宕机感知”的运维保障能力。
