beego 2.x 官方不内置限流中间件，需基于 golang.org/x/time/rate 自行封装轻量中间件，用 sync.map 按路径或用户 id 缓存独立 *rate.limiter 实例，并通过 beego.insertfilter() 注册，响应统一返回 http 429 状态码及 retry-after 头。
Beego 中限流该用哪个中间件
Beego 2.x 官方不内置限流中间件，beego.Middleware 体系里没有 RateLimit 或类似名称的现成组件。你得自己集成或封装，最稳妥的做法是基于 golang.org/x/time/rate（即 rate.Limiter）写一个轻量中间件，而不是依赖第三方 Beego 插件——那些插件往往更新滞后、文档缺失、不兼容新版本。
常见错误是直接在 Controller 的 Prepare() 里硬编码限流逻辑，这会导致复用困难、配置分散、无法统一监控。
- 限流逻辑必须作为独立中间件注册到路由层，比如用
beego.InsertFilter() - 避免在每个 Controller 里重复调
limiter.Allow()，否则后期调整策略要改十几处 - 别用内存 map 自己实现计数器，高并发下会丢数据且无滑动窗口支持
如何正确初始化 rate.Limiter 并绑定到请求路径
限流粒度通常按 URL 路径（如 /api/v1/users）或用户标识（如 X-User-ID header）区分。Beego 的 context.Input.URL() 可取路径，但注意它不含 query string，适合做路径级限流；若需用户级，应从 ctx.Input.Header("X-User-ID") 提取。
关键点：每个路径/用户应持有独立的 *rate.Limiter 实例，不能全局共用一个——否则所有请求挤同一桶，失去分流意义。
- 用
sync.Map缓存不同 key 对应的*rate.Limiter，key 可以是path或userID + path -
rate.NewLimiter(rate.Every(1*time.Second), 10)表示每秒最多 10 次，注意第一个参数是time.Duration，不是整数 - 初始化 limiter 时不要用太小的 burst（如 1），否则偶发延迟请求容易被拒，建议 burst ≥ 2×QPS 基线
中间件中怎么返回标准限流响应
HTTP 429 Too Many Requests 是唯一语义正确的状态码，Beego 默认不设这个状态，必须手动写 ctx.Abort(429) 并输出 JSON 或纯文本。别用 ctx.Output.SetStatus(429) 后继续执行后续逻辑——Abort() 才会中断流程。
常见错误是只设状态码但没写响应体，导致前端收空响应；或者返回 500 掩盖真实原因，排查时误判为服务异常。
- 推荐响应格式：
{"code":429,"message":"rate limit exceeded"}，字段名保持和项目其他接口一致 - 加
Retry-After: 1header，值为秒数（整数），告诉客户端等多久再试 - 避免在响应里暴露 limiter 内部细节，比如当前剩余次数（
lim.Burst()值），这属于敏感信息
上线前必须检查的三个兼容性坑
Beego 2.0+ 使用 github.com/beego/beego/v2，旧版 github.com/astaxie/beego 的中间件注册方式（如 InsertFilter 参数顺序）已变，混用会 panic。
- 确认
go.mod里引用的是github.com/beego/beego/v2，且版本 ≥ v2.0.0 - Beego 的
InsertFilter第二个参数类型在 v2 是func(http.Handler) http.Handler，不是旧版的func(*context.Context) - 如果用了
beego.RunWithMiddleWares()，中间件顺序很重要：限流中间件必须在鉴权之后、业务逻辑之前，否则未登录用户也能耗尽配额
限流规则本身没多复杂，难的是 key 的设计粒度、burst 值的压测验证、以及和 Prometheus 的指标对齐——这些不在代码里，但在上线后第一周就会暴露。
