beego中应使用golang.org/x/time/rate.limiter实现令牌桶限流，为每路径或用户id创建独立实例，通过lru缓存管理避免内存泄漏，并动态加载限流配置以支持热更新。
Beego 中如何用 golang.org/x/time/rate 实现令牌桶限流
Beego 本身不内置限流中间件，得自己写；最稳妥的选择是复用 Go 官方维护的 rate.Limiter，它就是标准的令牌桶实现。别自己手撸计数器或滑动窗口——精度低、并发不安全、还难调。
关键点在于：每个路由路径（或用户 ID）需绑定独立的 rate.Limiter 实例，否则所有请求共用一个桶，会误伤正常流量。
-
rate.NewLimiter(rate.Every(1*time.Second), 5)表示“每秒补充 5 个令牌，初始桶容量 5” - 在 Beego 的
Controller.Run前拦截，调用limiter.Allow()或limiter.Wait(ctx) - 注意：Beego 1.x 的
Prepare()方法适合放限流逻辑；2.x（基于 Gin）则用Use()注册中间件
按请求路径做粒度控制时，如何避免内存泄漏
如果为每个 RouterPattern 动态 new 一个 rate.Limiter，又不回收，长期运行后 map 会无限增长。不是所有路径都值得单独限流，得有兜底和清理机制。
- 用固定大小的 LRU cache（比如
github.com/hashicorp/golang-lru）存path → *rate.Limiter映射，超容时淘汰冷路径 - 对通配路径（如
/api/v1/users/:id）统一映射到模板键/api/v1/users/:id，而不是真实 URL - 避免用完整 query string 做 key（
?t=123&v=456变化多），只取ctx.Input.URI()的 path 部分 - 测试时故意触发 429 后观察 goroutine 数是否稳定，突增说明 limiter 创建失控
Beego 1.x 的 Prepare() 中怎么安全调用 limiter.Wait()
直接在 Prepare() 里调用 limiter.Wait(ctx) 会阻塞整个 controller 执行，且 Beego 1.x 的 context.Context 不是 request-scoped 的，容易传错或超时失效。
- 改用
limiter.Allow()—— 它非阻塞，返回 bool，适合快速决策 - 若必须等（比如允许排队等待令牌），需手动构造带 timeout 的 context：
ctx, cancel := context.WithTimeout(context.Background(), 200*time.Millisecond)，并在 defer 中cancel() - 别把 limiter 存在
Controller结构体字段里——Beego 会复用 controller 实例，导致 limiter 被多个请求共享 - 错误日志里记录被限流的
ctx.Input.IP()和ctx.Input.URL()，方便后续按 IP 拆分限流策略
为什么不能直接在 config.yml 里配全局 QPS 而要动态加载
硬编码在配置文件里的限流阈值，在服务上线后无法热更新。一次发布就要重启，线上突发流量时来不及响应。
- 把限流参数存在 etcd / Redis，用
go.etcd.io/etcd/client/v3监听 key 变更，收到通知后替换对应路径的 limiter 实例 - Beego 的
AppConfig.String("limit::/api/pay")这种方式只能读启动时快照，不适合动态场景 - 如果用 Redis，注意
rate.Limiter本身不支持分布式，单机限流 + 配置中心下发，是 Beego 场景下最易落地的组合 - 上线前压测时，重点看
rate.Limiter.Limit()返回值是否随配置变更实时变化，这是验证热更新是否生效的关键指标
真正麻烦的不是写通逻辑，而是路径归一化规则和 limiter 生命周期管理——这两处出问题，监控上看不出明显报错，但限流会大面积失效或误触发。
