Beego需集成ulule/limiter/v3实现IP级滑动窗口限流，避免手动计数或time.Ticker等错误方式；注意IP提取逻辑、路径过滤精度、ctx.Abort后显式return及多维度限流key设计。
Beego 本身不提供开箱即用的接口限流能力，必须自行集成第三方限流库（如 ulule/limiter）或用 Go 官方 golang.org/x/time/rate 手动封装中间件。直接靠 beego.InsertFilter + 计数器 + 时间窗口是容易出错的土办法，尤其在并发或重启后计数丢失时会失效。
用 ulule/limiter 实现 IP 级滑动窗口限流
这是 Beego 生产环境最稳妥的做法：基于内存存储、支持滑动窗口、自动清理过期记录，且与 Beego 的 context.Context 兼容。
-
ulule/limiter/v3的memory.NewStore()是线程安全的，适合单机部署；若需多实例共享状态，得换redisstore（但 Beego 默认没集成 redis client，需额外引入） - 注意版本 ——
ulule/limiterv2 和 v3 的 API 不兼容，v3 的Get()返回limiter.Context，含Reached和Remaining字段，别用错 - IP 提取逻辑要小心：
limiter.GetIP()默认信任X-Forwarded-For，但 Beego 前面若没配 nginx 或信任头，会导致所有请求被识别为同一个 IP（比如127.0.0.1） - 示例中
beego.InsertFilter("/*", beego.BeforeRouter, ...)会拦截所有路由，包括静态文件；如只需限流 API，应改为"/api/*"或更精确路径
别用 time.Ticker 或 time.Sleep 模拟限流
这类写法在 Beego 中常见但危险：它只控制「发请求的节奏」，不感知实际请求是否完成、是否失败重试、是否堆积。比如一个耗时 2 秒的请求，time.Sleep(1 * time.Second) 仍会每秒触发一次，瞬间并发就破限。
- Beego 的 HTTP handler 是并发执行的，
time.Sleep只阻塞当前 goroutine，不影响其他请求进入 -
time.Ticker无法关联请求生命周期，也不能统计「过去 60 秒内真实完成的请求数」，滑动窗口需求完全无法满足 - 错误日志里出现大量
429 Too Many Requests却查不到限流逻辑生效，大概率就是混用了 Ticker + 手动计数
自定义限流中间件必须处理 ctx.Abort 后的流程中断
Beego 的 ctx.Abort() 不会自动退出 handler 函数，后续代码仍会执行 —— 这是高频踩坑点。
- 限流检查后必须紧跟
return，否则即使返回了429，控制器里的数据库查询、日志写入等逻辑还会跑 - 示例中
RateLimit函数末尾缺return，就会导致ctx.Abort(http.StatusTooManyRequests, "429")后继续往下走 - 建议统一用
if limiterCtx.Reached { ctx.Abort(...); return }模式，避免漏掉return - 如果要用 Beego 的错误页机制（如
beego.ErrorMaps），需确保Abort的 status code 已注册，否则可能 fallback 到默认 500 页面
真正难的不是接入限流库，而是把「谁来限」「按什么维度限」「窗口怎么算」「失败后怎么降级」想清楚。比如用户登录接口要按 IP + 用户名双维度限流，就得构造复合 key；而全局 QPS 限制又得单独一套共享 bucket —— 这些逻辑都在 RateLimit 函数里，不在配置项里。
