Beego中间件优雅降级需三要素：用ResponseWriter直写响应（绕过未初始化的c.Data）、熔断器全局复用且按依赖隔离、静态资源降级必须注册BeforeStatic过滤器。
beego.InsertFilter 是注册中间件的唯一入口，但“优雅降级”不是靠它单点配置出来的——它需要中间件函数内部做 fallback 判断、配合熔断器状态、并规避 Beego 上下文生命周期限制。
Beego 中间件里不能直接调用 c.ServeJSON() 或 c.Data
很多开发者想在中间件里拦截失败后直接返回降级响应，比如 503 或缓存兜底数据，结果 panic。原因很实在：c.Data 和 c.TplName 只在 Controller 的 Prepare() 之后才初始化；而中间件（尤其是 BeforeRouter 或 BeforeStatic）执行时，Controller 实例根本还没创建。
可行做法是：只写响应头 + 直接写 body，绕过 Beego 渲染链：
func FallbackFilter(ctx *context.Context) {
if shouldFallback() {
ctx.ResponseWriter.WriteHeader(503)
ctx.ResponseWriter.Write([]byte(`{"code":503,"msg":"service unavailable"}`))
ctx.ResponseWriter.Header().Set("Content-Type", "application/json; charset=utf-8")
return // 不调 ctx.Next()
}
ctx.Next()
}- 必须显式
return，否则ctx.Next()还会继续执行后续逻辑 - 不要用
c.Ctx.Output.JSON()—— 它依赖c.Data，此时为 nil - 若需返回 HTML 降级页，得自己读文件 + 写入
ResponseWriter，不能依赖views/模板系统
gobreaker.CircuitBreaker 必须全局复用，且不能放在中间件函数里初始化
把 gobreaker.NewCircuitBreaker 写在中间件函数体内，等于每次请求都新建一个熔断器，统计窗口失效，完全起不到熔断作用。
正确姿势是包级变量或依赖注入：
var userSvcCB = gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "user-service-call",
Timeout: 60 * time.Second,
Interval: 60 * time.Second,
MaxRequests: 10,
})- 每个外部依赖（如 Redis、支付、用户中心）配独立实例，命名带业务标识
- 中间件里只做「是否允许通行」判断：
if userSvcCB.State() == gobreaker.StateOpen { ... } - 真正调用下游的地方（比如 service 层的
GetUserByID()）才包裹cb.Execute()，中间件不越界
静态资源路径 /static/ 的降级必须用 BeforeStatic 阶段注册
你在 BeforeRouter 里写的权限校验或降级逻辑，对 /static/private/file.pdf 完全无效——Beego 的静态处理器压根不走路由层。
要拦截静态请求并做降级（比如返回占位图、跳转登录页、或记录 404 后自动回源），必须：
beego.InsertFilter("/static/", beego.BeforeStatic, staticFallbackFilter)-
BeforeStatic阶段的ctx不含ctx.Input.Param()，参数得手动从ctx.Request.URL.Path解析 - 不能调
ctx.Controller、ctx.Input.Session等字段，它们未初始化，会 panic - 降级响应只能靠
ctx.ResponseWriter直写，且注意 MIME 类型（比如返回 PNG 要设image/png）
中间件内做超时控制，必须派生新 context.Context，不能复用 handler 全局 ctx
context.WithTimeout(c.Ctx, 200*time.Millisecond) 看似合理，实则危险：这个 ctx 一旦超时取消，会连带中断整个 HTTP 请求上下文，导致 ctx.Next() 后续流程无法执行，甚至影响日志、监控等基础能力。
- 真正该加超时的地方是下游调用点，比如
redisClient.Get(timeoutCtx, key)或http.DefaultClient.Do(req.WithContext(timeoutCtx)) - 中间件里只负责判断「是否已超时」或「是否触发熔断」，不主动 cancel handler ctx
- 如果真要限流或快速失败，用计数器 + 时间窗口（如
golang.org/x/time/rate.Limiter）比 context 超时更可控
Beego 的中间件降级不是“加个开关就生效”的功能，它本质是控制流与生命周期的精细协同。最容易被忽略的点是：所有 fallback 响应必须脱离 Beego 的 Controller 生命周期，用原始 ResponseWriter 直写；所有熔断器必须按依赖维度隔离、全局复用；所有静态资源拦截必须落在 BeforeStatic 阶段——这三个约束漏掉任何一个，降级都会静默失效。
