Beego中间件测试必须手动构造*context.Context并显式触发过滤器链，不可用beego.BeeApp.Handlers.ServeHTTP；需按BeforeRouter/BeforeStatic/BeforeExec等注册阶段差异模拟上下文，正确断言状态变更或响应结果。
Beego 中间件不能靠 beego.BeeApp.Handlers.ServeHTTP 直接测试，必须模拟 *context.Context 并手动触发过滤器链——因为中间件注册后不参与标准 HTTP handler 流程，而是由 Beego 内部在特定阶段（如 BeforeRouter）主动调用。
构造可测试的中间件函数签名
Beego 中间件函数签名固定为 func(*context.Context)，且必须显式调用 ctx.Next() 才能继续流程。测试时不能依赖真实请求上下文，需手动构造最小可用的 *context.Context 实例：
- 用
httplib.NewRequest或http.NewRequest创建*http.Request - 用
context.NewContext()初始化上下文（Beego v2 中位于github.com/beego/beego/v2/server/web/context） - 将
Request和空ResponseWriter注入context.Context的Ctx字段 - 避免直接 new struct，否则
ctx.Input.Param()等方法会 panic
拦截点差异决定测试方式
不同 InsertFilter 阶段的中间件，测试逻辑完全不同：
-
beego.BeforeRouter：所有请求都走，可安全使用ctx.Input.URI()和ctx.Input.Method() -
beego.BeforeStatic：仅静态路径（如/static/）触发，ctx.Input.Param()未解析，需手动从ctx.Request.URL.Path提取 -
beego.BeforeExec：路由已匹配，ctx.Input.Param(":id")可用，但控制器尚未执行 - 测试前务必确认你注册的是哪个阶段——写错阶段会导致测试通过但线上不生效
验证中间件行为的关键断言点
中间件不返回值，效果体现在上下文状态或响应结果上。常见可测行为包括：
- 调用
ctx.Abort(401, "xxx")后，w.Code应为 401，且w.Body.String()包含预期错误信息 - 修改了
ctx.Output.Status，需在后续 handler 中读取并断言 - 设置了 session：
ctx.Input.Session.Set("user_id", 123)，可在测试中用ctx.Input.Session.Get("user_id")验证 - 未调用
ctx.Next()时，后续逻辑应完全跳过——建议在被测中间件后挂一个“探针中间件”来确认是否执行
绕过 Beego 初始化陷阱
别在测试里调 beego.TestBeegoInit() ——它只初始化路由和配置，对过滤器注册无影响。中间件测试必须独立于 Beego 应用生命周期：
- 在测试函数内直接调用你的中间件函数，传入构造好的
*context.Context - 若中间件依赖全局配置（如
beego.AppConfig.String("auth::token_key")），需提前用beego.LoadAppConfig("ini", "conf/app.conf")加载 - 避免在
BeforeSuite中注册过滤器——Ginkgo 的并发测试可能造成 filter 覆盖冲突 - 每个测试用例应 clean up 自己注册的 filter，例如用
beego.ResetFilters()（v2 中存在）或重置全局变量
真正难的不是写断言，而是还原中间件实际运行时的上下文状态：比如 BeforeStatic 阶段的 ctx.Ctx.ResponseWriter 是只写的，ctx.Data 是 nil，这些细节不模拟到位，测试就只是空中楼阁。
