beego 本身不提供内置限流能力，必须集成第三方库（如 ulule/limiter）或手写逻辑；直接用 go 标准库 rate.limiter 易出现 ip 提取错误、context 取消遗漏、burst 配置失当、无跨进程共享存储等问题，且其单实例无状态模型与 http 多维度限流需求不匹配。
Beego 本身不提供内置限流能力，必须集成第三方限流库（如 ulule/limiter）或手写逻辑；直接用 rate.Limiter 在 Beego 中需自行管理生命周期，容易漏掉 context 取消、IP 提取错误、Burst 配置失当等坑。
为什么不能直接用 rate.Limiter 做全局 HTTP 限流
Beego 的请求生命周期和 rate.Limiter 的使用模型不天然对齐：
-
rate.Limiter是单实例、无状态的令牌桶，但 HTTP 限流必须按 IP、用户、路径等维度隔离，需自己做 key 管理（比如"ip:192.168.1.100"） - 它不自动感知请求结束，
Reserve()返回的Reservation必须显式调用Cancel()或OK()，否则会泄漏资源 - 没有存储后端支持——内存 store 无法跨进程共享，K8s 多副本下限流失效；Redis store 需额外依赖和配置
- Beego 的
context.Context生命周期短于请求处理全程，若在BeforeRouter中调用Wait()，超时后 panic 会中断整个中间件链
推荐方案：用 ulule/limiter + 内存 store 快速落地
这是目前 Beego 生产项目中最轻量、最可控的选择，ulule/limiter 封装了 key 构造、store 交互、HTTP 头写入等细节，避免重复造轮子。
- 安装：
go get github.com/ulule/limiter/v3 - 初始化限流器（放在
main.go或配置初始化处）：store := memory.NewStore() rate, _ := limiter.NewRateFromFormatted("100-S") // 每秒 100 次 limiterInst := limiter.New(store, rate) - 注册过滤器（
BeforeRouter阶段）：beego.InsertFilter("/*", beego.BeforeRouter, func(ctx *context.Context) { ip := limiter.GetIP(ctx.Request, limiter.Options{}) ctxKey := ip.String() limiterCtx, err := limiterInst.Get(ctx.Request.Context(), ctxKey) if err != nil { ctx.Abort(http.StatusInternalServerError, "limiter error") return } if limiterCtx.Reached { ctx.Abort(http.StatusTooManyRequests, "429") return } }) - 注意：
limiter.GetIP()默认信任X-Forwarded-For，若部署在 Nginx 后，需显式传入TrustForwardHeader: true，否则所有请求都识别为127.0.0.1
Beego 过滤器位置选错会导致限流失效
限流必须在路由匹配前完成，否则控制器已执行一半才拒绝，资源（DB 连接、日志 IO）已被浪费。常见错误位置及后果：
-
BeforeExec：控制器方法已反射调用，this.Ctx.Input.Param()已解析，可能触发 DB 查询或缓存读取 -
AfterExec：响应体已生成，此时 abort 只能覆盖 status code，前端仍收到部分响应内容 -
FinishRouter：请求早已完成，限流完全失去意义 - 正确位置只有
BeforeRouter—— 它在 URL 匹配、参数提取、Controller 实例化之前执行，是唯一能“拦在门口”的时机
Burst 设置过大或过小都会引发线上问题
ulule/limiter 底层也用 rate.Limiter，它的 Burst 参数对应 limiter.NewRateFromFormatted 中的速率字符串隐含值（如 "100-S" 默认 Burst=100），但你无法直接控制。若需精细调节突发容量，必须换用底层 rate.Limiter 手动封装：
- Burst 过小（如
10）：API 调用方批量请求、重试、SDK 自带并发时，极易触发 429，误伤正常流量 - Burst 过大（如
1000）：相当于允许瞬间打穿后端，数据库连接池、下游接口配额可能被耗尽 - 经验公式：
Burst ≈ 平均 QPS × 0.5~2 秒，例如平均 200 QPS，Burst 设为 200~400 较稳妥 - 真正需要动态调参时，别硬改配置文件重启服务，而是把
*rate.Limiter放进sync.Map，key 为 route 或 user_id，运行时用SetLimit和SetBurst更新
限流不是加个中间件就完事——IP 识别是否准确、Burst 是否贴合业务毛刺、多副本下是否共享状态，这三个点任何一个出错，线上就会出现“限了等于没限”或“不该限的全被拦”。尤其注意 Beego 的 BeforeRouter 过滤器里不能做阻塞 IO（如查 Redis），否则整个路由匹配会被拖慢。
