Beego中间件本质是函数链，通过beego.InsertFilter注册，无容器概念；必须在beego.Run()前调用，依赖需闭包捕获，Docker部署时须显式挂载配置并确保服务依赖。
Beego 没有中间件“容器”概念，所谓“中间件容器化部署”本质是混淆了两个独立问题：Beego 的中间件机制（beego.InsertFilter）和应用整体的容器化（Docker + docker-compose.yml）。直接套用 Spring Boot 那套“中间件注册到容器”的思路，在 Beego 里会失败。
Beego 中间件不是可注入对象，而是函数链
Beego 的中间件必须是符合 func(http.ResponseWriter, *http.Request) 或 func(*context.Context) 签名的函数，通过 beego.InsertFilter 注册。它不支持构造、生命周期管理或依赖注入——没有“容器”来 hold 它们。
- 常见错误：写一个带字段的 struct 并期望在中间件里访问
DB或Cache，结果 panic：字段全为零值 - 正确做法：所有依赖需提前初始化并以闭包方式捕获，例如
authMiddleware(db *sql.DB)返回实际中间件函数 - 不能在
init()里调用beego.InsertFilter，因为此时配置未加载，beego.AppConfig.String("jwt::secret")可能为空 - 中间件执行顺序严格按
InsertFilter调用顺序，越早注册越先执行（前置）或越后执行（后置），不支持优先级权重
Docker 化时中间件行为不会自动迁移
把 Beego 应用打包进 Docker 镜像，中间件逻辑本身不会变化，但环境变量、配置文件路径、网络可达性等外部条件极易出错，导致中间件静默失效。
- 典型现象：
JWTAuthMiddleware在本地跑通，容器里返回 401 且无日志——大概率是conf/app.conf没挂载进容器，或runmode = prod下读不到测试密钥 - 务必在
Dockerfile中显式复制配置目录：COPY conf/ /app/conf/，不能只靠bee dockerize自动生成的模板 - 若中间件依赖 Redis 或 MySQL，
docker-compose.yml中必须定义服务依赖（depends_on）并加健康检查，否则 Beego 启动时连接失败，InsertFilter还没注册就 panic 退出 - Nginx 反向代理下，
X-Forwarded-For和X-Real-IP头可能被截断，导致 IP 限流中间件误判——需在 Nginx 配置中显式透传：proxy_set_header X-Real-IP $remote_addr;
Beego v2 路由与中间件配合的坑
Beego v2 引入了 beego.Router 和 beego.NSRouter 分层，但中间件注册仍全局生效，容易和路由组产生意外交互。
- 错误写法：
ns := beego.NewNamespace("/api"); ns.Filter("*", myMiddleware); beego.AddNamespace(ns)—— 这个myMiddleware实际对所有路由生效，不只是/api下的 - 正确限定范围：用
NSFilter替代Filter，且确保AddNamespace在所有InsertFilter之后调用，否则命名空间过滤器不生效 - 自定义中间件若调用
this.Abort()，必须保证this.Ctx.Output.SetStatus(403)等状态码已设置，否则默认返回 200 + 空响应体，前端难排查 - 日志中间件里不要直接用
fmt.Println，应走beego.Trace或beego.Info，否则容器日志收集（如 Fluentd）无法打标和过滤
最易被忽略的一点：Beego 中间件函数内不可调用 beego.BeeLogger 的异步写入方法（如 AsyncWrite），因为中间件执行栈不属于 Beego 主循环，日志可能丢失或阻塞请求。所有日志操作必须同步完成。
