Beego中间件本身不拖慢请求，但写法不当会直接卡死；需避免在BeforeRouter查Redis、禁用未超时远程调用、控制中间件数量在5个以内，并杜绝memory.Cache用于业务数据。
Beego中间件本身不拖慢请求，但写法不当会直接卡死
Beego中间件的执行模型是同步串行的，每个中间件函数在同一个goroutine里顺序调用，ctx.Next()之后才进下一个。它不自带协程调度开销，性能损耗几乎为零——前提是中间件里别干耗时的事。
常见卡死现象：http: Accept error: accept tcp [::]:8080: accept4: too many open files 或 CPU 100% 但 QPS 上不去。根本原因不是中间件机制，而是你在 BeforeExec 里写了未加超时的 HTTP 调用、没关的 DB 连接、或直接 time.Sleep()。
- 所有远程调用（HTTP / Redis / MySQL）必须包裹
ctx.SetTimeout()，别依赖全局 context - 禁止在中间件里调
o.ReadOrCreate()或o.QueryTable().All()—— ORM 查询会阻塞整个 goroutine -
log.Printf()比ctx.Input.CruTime慢 3–5 倍，高并发下日志中间件要改用异步写入或结构化日志库
Beego中间件位置选错，路由匹配就退化成 O(n)
很多人把权限校验逻辑塞进 BeforeRouter，结果发现 QPS 掉一半。这不是中间件的问题，是位置选错了：Beego 的 BeforeRouter 在路由树匹配前执行，所有请求（包括 /static/js/app.js）都得过一遍，白耗 CPU。
正确做法是按阶段拆分：
-
BeforeStatic：只处理静态资源路径，比如加缓存头、防盗链校验 -
BeforeRouter：仅做全局轻量操作，如注入 trace ID、解析通用 header -
BeforeExec：控制器执行前做业务相关检查，比如 JWT 解析、活动时间判断 - 绝对不要在
BeforeRouter里查 Redis 或调数据库 —— 此时连路由都没匹配，1000 个静态请求也得等你查完 Redis 才放行
中间件里用 memory.Cache 就是给自己埋雷
Beego 自带的 cache.NewCache("memory", ...) 底层是 map + sync.RWMutex，高并发读写锁争用严重。实测 5000 并发请求同一 key，平均延迟从 0.2ms 拉到 12ms，比直连 Redis 还慢。
更危险的是缓存穿透场景：比如秒杀商品详情中间件里用 memory.Cache 缓存 item:123，缓存 miss 后直接打 DB，5000 个请求全走一遍 ORM，DB 连接池瞬间打满。
- 本地缓存只用于极低频、无共享需求的配置项（如
app.version），且必须设CacheSize - 所有业务数据缓存统一走 Redis，中间件里用
redis.Client.Get(ctx, key)，别绕路经 Beego cache 模块 - 对高频 key（如
user:token:xxx），中间件里加一层if strings.HasPrefix(ctx.Request.URL.Path, "/api/")快速跳过非 API 请求
中间件链越长，goroutine 堆栈越容易溢出
Beego 默认不限制中间件嵌套深度，但 Go 的 goroutine 默认栈是 2KB，每层中间件调用增加约 128B 栈帧。16 层中间件后，栈占用超 2KB，触发栈扩容，GC 压力陡增。线上曾出现 runtime: goroutine stack exceeds 1000000000-byte limit panic。
真实项目中，中间件数量应控制在 5 个以内：
- 1 个 trace ID 注入（
BeforeRouter） - 1 个跨域/安全头设置（
BeforeRouter） - 1 个登录态校验（
BeforeExec） - 1 个参数预处理（
BeforeExec） - 1 个响应日志（
FinishRouter） - 别为了“功能解耦”硬拆中间件——把 token 解析和权限检查合并成一个函数，比两个中间件快 40%
Beego 中间件真正的性能瓶颈，从来不在框架层，而在你是否清楚每个 ctx.Next() 调用背后，正在阻塞多少个 goroutine。
