Beego v2 中间件机制彻底重写：注册必须显式调用 beego.InsertFilter() 且在 Run 前完成，Prepare() 已移除；函数签名改为 *context.Context，路径参数用 PathParam()，短路用 Abort() 或 StopRun()，panic 需手动 defer recover。
Beego v2 的中间件机制不是“变化”，而是彻底重写：v1 的 InsertFilter 语义保留但底层生命周期暴露，v1 的 Prepare() 方法在 v2 中已失效，必须改用显式注册 + 上下文控制。
中间件注册方式从隐式变显式，且必须在 Run 前完成
v2 不再允许在 controller 里靠 Prepare() 拦截请求——该方法已被移除。所有中间件必须通过 beego.InsertFilter() 显式注册，且调用位置严格限定在 beego.App.Run() 之前（通常在 main() 函数开头）。
- 路径匹配更严格：
"/api/"（带尾部斜杠）才匹配/api/users；写成"/api"会意外匹配/apixxx - 过滤点类型不能混用：
beego.BeforeRouter对静态资源无效，要拦截/static/必须用beego.BeforeStatic - 注册顺序即执行顺序：多个中间件注册到同一过滤点时，先注册的先执行
中间件函数签名和 ctx 使用方式变了
v2 的中间件函数接收的是 *context.Context，不再是 v1 的 *controllers.Controller。这意味着你不能再直接访问 c.Data、c.TplName 等模板相关字段，也不能调用 c.Redirect() 等响应方法。
- 获取路径参数：从
c.Ctx.Input.Param(":id")改为c.PathParam("id") - 读取请求体：需手动调用
c.ParseForm()或c.ParseJSON()，且仅应在 POST/PUT/PATCH 中调用，否则阻塞 GET - 短路处理：不再用
return跳过后续逻辑，而应调用c.Abort("401")或c.StopRun()终止流程 - panic 恢复需自行
defer：v2 不再自动 recover，不加defer func() { if err := recover(); err != nil { ... } }()会导致整个服务崩溃
静态资源、路由、API 三类请求必须分三套中间件注册
v2 明确拆分了请求处理阶段：静态文件走独立路径，完全绕过路由系统；API 和页面请求才进入 BeforeRouter 链。想统一鉴权？得写三遍逻辑。
-
beego.BeforeStatic：能拿到c.Ctx.Request和c.Ctx.ResponseWriter，但c.Input为空，无法解析表单或路径参数 -
beego.BeforeRouter：适用于 API 鉴权、日志、限流等通用逻辑，可完整访问请求上下文 -
beego.BeeApp.FilterType已废弃，v2 中必须使用明确的过滤点常量，如beego.BeforeRouter - 若同时限制
/api/和/static/private/，必须分别调用两次beego.InsertFilter()
限流、鉴权类中间件容易踩内存计数和范围错配的坑
v2 仍保留 LimitFilter，但它仍是单机内存计数，未集成 Redis 或滑动窗口。线上直接用等于没限。
- 固定窗口缺陷明显：每分钟 600 次限制，若第 59 秒涌入 600 请求，第 0 秒又来 600，实际峰值达 1200
- 不感知处理耗时：一个接口平均耗时 2s，
LimitFilter仍按 1s 计数，导致并发堆积 - 路径前缀注册错误：注册
"/user"却想拦/user/profile，结果漏掉；必须写"/user/" - 真正可靠的削峰方案是把耗时操作投递到 RabbitMQ，并设
prefetchCount = DB 连接池大小，而不是在中间件里做计数
最易被忽略的是：v2 把整个初始化生命周期交给了开发者。你不再能依赖框架自动加载配置、自动挂载中间件、自动 recover panic——每一处都得自己写、自己排、自己测。迁移时卡住的往往不是语法，而是某一行 beego.InsertFilter() 漏写了，或某个 c.StopRun() 忘了调用。
