Beego中间件中panic无法recover是因为recover必须与panic同goroutine且中间件未自动包裹defer；正确做法是在中间件开头显式defer recover并调用ctx.Abort()或return终止请求。
Beego 中间件里 panic 为什么 recover 不了
因为 Beego 的中间件执行时，recover() 必须在和 panic() 同一个 goroutine 中调用，而中间件函数本身不自动包裹 defer。如果你在中间件里直接写 panic("test")，又没手动加 defer func() { recover() }()，它就会穿透出去，被框架默认的 recoverPanic 捕获（返回 500），但你完全看不到日志或自定义逻辑。
- Beego 的
InsertFilter注册的中间件是裸函数，不带任何恢复机制 - 不能依赖 main 函数或 init 里的
defer recover—— 它们只在主线程生效，对中间件 goroutine 无效 - 中间件中调用的第三方库（如 ORM、HTTP client）若 panic，也会直接逃逸，除非你在中间件内部显式拦截
在 Beego 中间件里正确捕获 panic 的写法
必须把 recover() 写进中间件函数体最开头，并确保它在 ctx.Next() 前完成注册。顺序错了就失效。
func panicRecoveryMiddleware(ctx *context.Context) {
defer func() {
if r := recover(); r != nil {
logs.Error("PANIC in middleware: %v, stack: %s", r, debug.Stack())
// 注意：此时 ctx.ResponseWriter 可能已部分写入，不要重复 WriteHeader
if ctx.ResponseWriter.Status == 0 {
ctx.ResponseWriter.WriteHeader(500)
}
ctx.ResponseWriter.Write([]byte("Internal server error"))
}
}()
ctx.Next()
}
-
defer必须在ctx.Next()之前声明，否则 panic 发生时 defer 还没入栈 - 检查
ctx.ResponseWriter.Status == 0是为了避免重复设置状态码（Beego 可能在后续流程中已设为 200） - 不要在 recover 块里调用
c.ServeJSON()或其他 Beego controller 方法 —— 中间件没有c实例，只有ctx
中间件异常和控制器异常要分开处理
Beego 的 recoverPanic = true 默认只覆盖 controller 方法（Get()/Post()），不覆盖中间件。所以中间件 panic 和 controller panic 是两套独立路径，不能混用同一套 recovery 逻辑。
- 中间件异常建议统一记录 + 返回 500，避免污染业务响应格式
- 如果中间件要做鉴权、限流等关键逻辑，panic 往往意味着严重 bug（比如空指针解引用），不应静默吞掉，而应触发告警
- 想让中间件异常也走和 controller 一样的错误上报链？只能手动复用同一段日志/告警代码，别试图“统一注入”——Beego 没提供跨层 recovery 注册点
真正影响线上稳定性的坑：recover 后状态码和 response body 不一致
很多开发者在中间件 recover 里写了 WriteHeader(500)，但忘了 Beego 默认会在 controller 执行完后自动写一次 200。结果响应头是 500，body 却是 controller 正常返回的 JSON，客户端解析失败。
- 最稳妥做法：recover 后立即
return，不调用ctx.Next()，彻底中断请求流程 - 或者用
ctx.Abort()（Beego v2.1+ 支持），它会跳过后续 filter 和 controller，但注意ctx.Abort()不会阻止已注册的 after-filter - 永远不要假设
recover()能“修复”panic 并继续执行 —— Go 的 panic 不是 exception，recover 后程序状态不可信，继续跑可能引发二次 panic
Beego 中间件异常捕获的关键不是“怎么写 recover”，而是“在哪一层决定终止请求”。一旦 panic 发生，goroutine 状态已损坏，强行续跑比直接 500 更危险。
