Beego 中无法直接用 golang.org/x/time/rate.Limiter 做用户级限流，因中间件注册后固化、全局 limiter 不支持动态更新，需用 sync.Map 缓存带过期时间的用户维度 *rate.Limiter 实例，并在 filter 中非阻塞调用 Allow()；生产环境建议移至网关层。
Beego 中无法直接用 golang.org/x/time/rate.Limiter 做用户级限流
Beego 的中间件（如 beego.InsertFilter）在启动时注册并固化，rate.Limiter 实例一旦创建就绑定到闭包或全局变量里，后续改配置、换阈值都不会生效——哪怕你用 atomic.Value 包一层，如果没把 Allow() 或 WaitN() 调用真正“动态路由”到当前实例，还是白搭。
常见错误是这样写：
var globalLimiter = rate.NewLimiter(rate.Every(time.Second/10), 10)
func rateLimitFilter(ctx *context.Context) {
if !globalLimiter.Allow() {
ctx.Abort(429)
return
}
}
这只能做全局限流，且改了 globalLimiter 变量也不会影响已运行的 goroutine 中的引用。
- 用户维度（如
userID、IP、api_key）必须构造独立的*rate.Limiter实例 - 不能靠 map[string]*rate.Limiter 硬存——GC 不友好，且无自动过期，容易内存泄漏
- Beego 没有类似 Gin 的
c.GetString("userID")这种统一上下文取值方式，得自己从ctx.Input.Param、ctx.Input.Header或ctx.Input.Cookie提取 key
用 sync.Map + time.Now().Unix() 实现带过期的用户限流器缓存
Go 标准库没有带 TTL 的并发安全 map，但可以用 sync.Map 存 key → *rate.Limiter，再配合时间戳判断是否过期。不推荐用第三方 cache 库（如 gocache），Beego 项目通常轻量，引入新依赖反而增加维护成本。
关键逻辑是：每次请求来，先查 sync.Map，命中则检查其创建时间是否超 30 分钟；未命中或过期，则新建一个 rate.NewLimiter 并存入。
var userLimiters sync.Map // string → *limiterEntry
type limiterEntry struct {
limiter *rate.Limiter
created int64 // Unix timestamp
}
func getLimiterForUser(key string, r rate.Limit, b int) *rate.Limiter {
if e, ok := userLimiters.Load(key); ok {
entry := e.(*limiterEntry)
if time.Now().Unix()-entry.created
- 注意
r和b必须从配置中心或atomic.Value动态读取，不能写死 - 不要用
time.Now().Sub(entry.created) > 30*time.Minute—— 在高并发下time.Now()调用本身有开销，Unix 时间戳更轻量 -
sync.Map的Load/Store是原子的，但不保证「查+存」的原子性，所以这里允许短暂重复创建，不影响正确性
Beego 中间件里怎么安全调用 Allow() 而不阻塞请求
Beego 的 filter 是同步执行的，rate.Limiter.WaitN() 会阻塞 goroutine，而 Beego 默认使用 goroutine 复用（非 per-request goroutine），阻塞可能拖慢整个 Mux。必须用 Allow() 或 TryConsume() 这类非阻塞方法。
提取 key 的位置很关键：Beego 的 ctx.Input.IP() 返回的是反向代理后的真实 IP，但如果你用了 Nginx，要确保它设置了 X-Real-IP；ctx.Input.Param(":id") 只在匹配路由时有效，别在全局 filter 里硬写，否则 panic。
func tokenBucketFilter(ctx *context.Context) {
userID := ctx.Input.Header("X-User-ID")
if userID == "" {
userID = ctx.Input.Cookie("user_id")
}
if userID == "" {
userID = ctx.Input.IP()
}
limiter := getLimiterForUser(userID, getCurrentRate(), getCurrentBurst())
if !limiter.Allow() {
ctx.ResponseWriter.WriteHeader(429)
ctx.ResponseWriter.Write([]byte(`{"error":"too many requests"}`))
ctx.Abort()
return
}
}
-
getCurrentRate()和getCurrentBurst()必须从atomic.Value读取，不能读配置文件或结构体字段 - 返回 429 时务必调用
ctx.Abort()，否则后续 filter 和 controller 仍会执行 - 不要在 filter 里做 redis 查询——Beego 启动默认不带异步 context，DB/redis 调用会卡住整个 HTTP handler
为什么生产环境建议把限流移到网关层
Beego 自身不是为高并发限流设计的：它没有连接池复用、无批量限流指令、不支持 Lua 脚本原子操作。当 QPS 上万时，每个请求都走 Go runtime 的 timer + channel（rate.Limiter 底层依赖），CPU 和 GC 压力明显上升。
真实线上问题常出在这里：
- 同一个用户短时间内发 100 个请求，
sync.Map里只存一个 limiter，但它的令牌桶状态是共享的——这没问题；可如果用户 A 和 B 共享一个 IP（比如 NAT 网关），你用 IP 做 key，就会误伤 - Beego 重启时
sync.Map全丢，所有用户限流状态重置，瞬间流量洪峰打垮下游 - 想做滑动窗口统计（比如“最近 60 秒内请求次数”），Beego 中间件没法高效维护时间序列数据，只能退化成固定窗口
复杂点在于：限流规则本身要能按路径、Header、Query 多维组合，还要支持熔断联动——这些 Beego 都不提供抽象接口，全得手撸，而 Spring Cloud Gateway 或 Kong 已经跑过千万级验证。别在框架短板上硬刚。
