Beego原生不支持分布式限流，因其为单进程MVC框架，本地计数器在多实例下失效；必须依赖Redis等外部存储，通过Lua脚本实现原子滑动窗口限流，并嵌入InsertFilter生命周期，同时注意性能、降级与连接池配置。
Beego 本身不提供分布式限流能力，所有基于 beego.Controller 的本地计数器（比如用 sync.Map 或全局变量）在多实例部署下必然失效——这是最常被忽略的前提。
为什么 Beego 原生不支持分布式限流
Beego 是 MVC 框架，不是网关，它的路由、中间件、Filter 都运行在单进程内。你写一个 BeforeExec 中间件做计数，这个计数只对当前实例有效；三台机器各放行 100 QPS，实际就涌进 300 QPS，Redis 连接池照样被打满。
常见错误现象：rateLimit(key, 100, 60, TimeUnit.SECONDS) 在每个 Beego 实例里都跑一遍，结果线上监控看到总请求量远超阈值，但单机日志显示“未超限”。
真正能用的分布式限流，必须依赖外部共享存储，而 Beego 不内置 Redis 客户端集成，也不封装原子计数逻辑（如 INCR + EXPIRE 组合），得自己补。
用 Redis 实现滑动窗口限流（推荐方案）
固定窗口有临界问题，漏桶/令牌桶在 Beego 场景下难与 HTTP 请求生命周期对齐（比如阻塞式取令牌会卡住整个 HTTP handler）。滑动窗口配合 Redis 的 ZSET 或 INCR + 过期时间是最务实的选择。
实操建议：
- 用
github.com/go-redis/redis/v8替代老版 redigo，它支持上下文取消和 pipeline - 限流 key 设计必须含维度标识，例如
rate:ip:192.168.1.100、rate:phone:138****1234，避免不同用户共用计数 - 不要用
GET+INCR两步操作，必须用 Lua 脚本保证原子性，否则并发下计数错乱 - 示例 Lua 脚本（用于每分钟最多 60 次）：
local key = KEYS[1] local expire = tonumber(ARGV[1]) local limit = tonumber(ARGV[2]) local current = redis.call("INCR", key) if current == 1 then redis.call("EXPIRE", key, expire) end return current <= limit
如何把限流嵌入 Beego 的 Filter 生命周期
Beego 的 InsertFilter 是唯一可控入口，但注意：Filter 执行时 c.Ctx.Input.Params 和 c.Ctx.Input.RequestBody 可能未完全解析，别在 Filter 里读 Body（会消耗流）。
使用场景：适合 IP、URL path、Header 中固定字段（如 X-App-ID）等轻量维度限流；不适合需反序列化 Body 解析手机号的场景（应后移到 Controller）。
关键点：
- Filter 函数中用
c.Ctx.Input.IP()获取真实客户端 IP，但要先配置BeegoApp.Config.Set("httpserver", "trustforwarded", true)并确保前置 Nginx 传了X-Forwarded-For - 别在 Filter 里直接调
c.Abort(429)，应返回布尔值控制是否继续，避免 panic - 限流失败时，用
c.Ctx.Output.SetStatus(429)+ 自定义 JSON 响应体，而非抛异常 - 示例 key 构造：
"rate:ip:" + c.Ctx.Input.IP()，避免硬编码字符串拼接，用fmt.Sprintf更安全
Beego + 分布式限流容易踩的坑
性能影响比想象中大：一次 Redis EVAL 往往耗时 0.5–2ms，在 QPS 过千时，这部分延迟会显著拉高 P99 延迟。
容易被忽略的点：
- Redis 连接池没设对：
PoolSize至少为maxThreads × 2，Beego 默认MaxProcs是 CPU 核数，但 HTTP 并发远高于此 - 没加 fallback：Redis 故障时不能全盘拒绝，应降级为本地内存计数（用
sync.Map+ 时间窗口），否则雪崩 - 没区分读写：限流判断是只读操作，但用了
client.Do而非client.Get等专用方法，可能误走到写节点（集群模式下） - 没清理过期 key：虽然用了
EXPIRE，但大量短时 key 会导致 Redis 内存碎片，需定期MEMORY PURGE或启用maxmemory-policy allkeys-lru
真正的难点不在算法实现，而在怎么让限流不成为系统瓶颈——它得快、得稳、得可退，而不是加完之后发现接口平均延迟涨了 15ms，运维半夜打电话问“是不是你们加了啥新东西”。
