Beego默认中间件不适合生产限流，因其无原子计数、无滑动窗口、不支持分布式，单机QPS上千即可能被击穿；需结合golang.org/x/time/rate或Redis+Lua实现可靠限流，并配置HTTP服务器超时参数防连接耗尽。
Beego 本身不提供开箱即用的全局限流中间件，直接靠 beego.Router 或 beego.InsertFilter 挂载一个计数器函数，扛不住真实高并发场景 —— 它没有原子计数、无滑动窗口、不支持分布式，单机 QPS 上千就可能被击穿。
为什么 Beego 的默认中间件不适合生产限流
很多人把限流逻辑写成一个闭包函数，用 map[string]int 记 IP 请求次数，再配个 time.AfterFunc 清空。这看似简单，但实际踩坑极多：
-
map非并发安全，没加sync.RWMutex就会 panic - 计时器无法精确控制时间窗口（比如“每秒最多 100 次”），
time.AfterFunc不保证准时触发 - 内存持续增长：未做 key 过期或 LRU 清理，恶意 IP 一扫就是几万条记录
- 完全无法横向扩展：集群部署时各节点各自计数，限流形同虚设
用标准库 golang.org/x/time/rate 做单机令牌桶
这是最轻量、最可控的方案，适合中小流量 API 或内部服务保护。核心是每个请求绑定一个 *rate.Limiter 实例（按 IP、用户 ID 或路由路径区分）：
示例代码片段：
var limiters = sync.Map{} // key: ip, value: *rate.Limiter
<p>func getLimiter(ip string) <em>rate.Limiter {
if lim, ok := limiters.Load(ip); ok {
return lim.(</em>rate.Limiter)
}
lim := rate.NewLimiter(rate.Every(time.Second/100), 100) // 100 QPS
limiters.Store(ip, lim)
return lim
}</p><p>func RateLimitMiddleware() beego.FilterFunc {
return func(ctx *context.Context) {
ip := ctx.Input.IP()
lim := getLimiter(ip)
if !lim.Allow() {
ctx.Abort(429, "Too Many Requests")
return
}
}
}
注意点：
- 不要对所有请求共用一个
*rate.Limiter，否则变成全局锁；按维度（如ctx.Input.Param(":id")）分桶更合理 -
rate.Every()和burst参数需根据业务容忍度调优：突发流量大就调高burst，但别超过 2×QPS - 该方式不清理旧 key，上线后建议加定时 goroutine 扫描
sync.Map并删除超 5 分钟无访问的 entry
Beego 中集成 Redis 实现分布式限流
当服务部署 ≥2 实例，或需按用户 token / app key 限流时，必须依赖外部存储。Redis + Lua 是目前最稳妥的选择，避免网络往返和竞态：
关键 Lua 脚本（存在 Redis 中，key 为限流标识，如 rate:ip:192.168.1.100）：
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local window_start = now - window
<p>redis.call("ZREMRANGEBYSCORE", key, 0, window_start)
local count = redis.call("ZCARD", key)
if count < limit then
redis.call("ZADD", key, now, now .. ":" .. math.random(1000, 9999))
redis.call("EXPIRE", key, window + 1)
return 1
else
return 0
end
在 Beego 中调用：
func RedisRateLimitMiddleware() beego.FilterFunc {
return func(ctx *context.Context) {
ip := ctx.Input.IP()
key := "rate:ip:" + ip
now := time.Now().Unix()
allowed, err := redisClient.Eval(ctx.Request.Context(), luaScript, []string{key}, 100, 60, now).Bool()
if err != nil || !allowed {
ctx.Abort(429, "Too Many Requests")
return
}
}
}
常见问题：
- Redis 连接池必须提前初始化且复用，别在每次中间件里 new client
- Lua 脚本中
EXPIRE时间要略大于窗口（如 60s 窗口设 61s），防止 key 提前消失 - 若用 Redis Cluster，确保 key hash tag（如
{rate:ip:192.168.1.100}）让同一 IP 总落在同一 slot
别忘了 HTTP 层本身的连接防护
限流只是最后一道防线。Beego 启动时若没配 http.Server 的超时参数，大量慢连接会先拖垮连接数和 goroutine：
-
ReadTimeout：设为5 * time.Second，防客户端发一半 request 就卡住 -
WriteTimeout：同样设为 5–10s，尤其后端依赖 DB 或日志写入时，避免协程 stuck 在WriteHeader -
IdleTimeout：最关键，设为60 * time.Second，否则 keep-alive 连接长期空闲不释放，FD 很快耗尽 - Beego 默认不暴露这些配置，得在
main.go启动时手动 wraphttp.Server
真正压测时，你会发现 80% 的“限流失效”其实源于连接没及时关，而不是令牌桶算错了。
