Beego中间件中panic无法自动recover，因中间件函数无默认defer-recover包裹，需手动添加defer func(){if r:=recover();r!=nil{...}}()并确保requestID在defer外获取、WriteHeader(500)在响应头未写入前调用。
Beego 中间件里 panic 为什么 recover 不了
中间件本身不自动包裹 defer recover()，panic 发生在中间件函数体内时，若没显式写 recover，就会直接向上冒泡到 Beego 默认的 recoverPanic 阶段——也就是你看到的 500 响应，但日志里没有你的自定义记录。
根本原因和控制器里一样：每个请求跑在独立 goroutine，而中间件函数只是这个 goroutine 里的一段同步执行逻辑。你在中间件里漏掉 defer func() { recover() }()，就等于把 panic 完全交给了框架兜底。
- Beego 的
InsertFilter注册的中间件是裸函数，不带任何异常保护 - 常见错误写法：
func(ctx *context.Context) { panic("oops") }—— 没 defer，没 recover，必然触发默认 500 - 正确姿势必须手动加一层
defer，且recover()要直接调用，不能包在另一个函数里（否则作用域错乱）
如何在中间件中统一捕获 panic 并记录 requestID
Beego 的 context.Context 在中间件阶段已初始化，ctx.Input.GetRequestID() 可用（前提是启用了 beego.RequestID 中间件或等效机制）。关键是要让 recover 和 requestID 绑定在同一作用域内。
示例代码：
beego.InsertFilter("/api/*", beego.BeforeRouter, func(ctx *context.Context) {
defer func() {
if r := recover(); r != nil {
reqID := ctx.Input.GetRequestID()
logs.Error("PANIC in middleware: %v, reqID=%s, stack=%s", r, reqID, debug.Stack())
// 可选：上报监控、发告警
ctx.ResponseWriter.WriteHeader(500)
ctx.ResponseWriter.Write([]byte("Internal server error"))
}
}()
// 中间件实际逻辑，比如鉴权、日志打点等
})
- 别在中间件里调
ctx.Abort()后还继续执行后续逻辑——它只是设置中断标记，不会 stop 当前函数执行 - 如果中间件需要提前终止请求，
ctx.Abort()后应立即 return，否则可能和 recover 冲突 - requestID 必须在 defer 外部先取出来，因为 recover 后 ctx 可能处于不可靠状态
中间件 panic 恢复后，为什么响应状态码还是 200
Beego 的 Context.ResponseWriter 是标准 http.ResponseWriter 封装，但它的 WriteHeader() 有“只生效一次”特性：一旦底层 http.ResponseWriter 已经写过 header（比如框架内部已写过 200），后续再调 WriteHeader(500) 就无效。
所以 recover 里改状态码必须满足两个条件：
- 确保还没触发任何
Write()或WriteString()（包括模板渲染、c.Data["xxx"]自动输出等） - 最好在中间件链最前端注册该 panic 恢复中间件（即
BeforeStatic或BeforeRouter），越早介入越容易控制 header - 如果业务逻辑已在 controller 层 panic，中间件里的 recover 就晚了——header 很可能已被 controller 渲染流程写死
用 ErrorHandler 替代中间件 recover？不推荐
beego.ErrorHandler("500", handler) 只接管 this.Abort("500") 这类显式中断，对 panic 完全无感。它和 recover 是两条平行路径：一个是主动抛出字符串错误并跳转，一个是被动拦截运行时崩溃。
混淆后果很实际：
- 你在中间件里
panic("db timeout")，却指望ErrorHandler("500", ...)捕获并渲染自定义页面——不会触发 -
this.Abort("dbError")是走 ErrorHandler，但panic("dbError")是走 recover 流程，二者语义完全不同 - 想统一错误出口，得靠中间件 + controller 两级 recover，而不是依赖 ErrorHandler
真正容易被忽略的是：recover 后的 response 写入必须绕过 Beego 的模板渲染流程，直接操作 ctx.ResponseWriter；一旦进入 c.TplName 渲染链，你就失去了对 HTTP 状态码和 body 的完全控制权。
