最稳妥的路子是「滑动窗口 + Lua 脚本」，因INCR+EXPIRE非原子操作，易致key永久存在或丢失、窗口错乱；必须用Lua保证计数与过期设置的原子性，并统一使用客户端传入的准确时间戳。
go 用 redis 做分布式限流，最稳妥的路子是「滑动窗口 + lua 脚本」，不是靠客户端拼逻辑，更不是用 incr + expire 两步走——那在并发下会漏统计、超阈值。
为什么不能只用 INCR 和 EXPIRE
因为这两条命令不是原子的。高并发时，可能先 INCR 成功，但 EXPIRE 失败（比如 key 刚被删或网络抖动），导致后续请求永远拿不到过期时间；或者多个客户端同时判断 TTL 为 -2（key 不存在），各自从 0 开始计数，瞬间冲垮阈值。
- 现象：
ERR no such key或限流失效，QPS 突然翻倍 - 根本原因：Redis 命令非原子，客户端无法靠 sleep/retry 补救
- 替代方案必须把「读+写+设过期」锁死在一次 Lua 调用里
用 Lua 脚本实现滑动窗口（固定时间粒度）
不推荐令牌桶（状态难同步）、也不用简单计数器（精度差）。滑动窗口折中了精度和性能，适合大多数 API 限流场景。核心思路：按秒/毫秒切分时间片，用 HSET 存每个窗口的计数，HEXISTS + HINCRBY + EXPIRE 全部塞进一个脚本。
示例脚本（保存为 sliding_window.lua）：
local key = KEYS[1]
local window_ms = tonumber(ARGV[1])
local max_count = tonumber(ARGV[2])
local now_ms = tonumber(ARGV[3])
<p>-- 清理过期窗口（只删比 now_ms - window_ms 更老的）
local old_ts = now_ms - window<em>ms
for </em>, ts_str in ipairs(redis.call('HKEYS', key)) do
local ts = tonumber(ts_str)
if ts < old_ts then
redis.call('HDEL', key, ts_str)
end
end</p><p>-- 当前窗口计数 +1
local current_count = redis.call('HINCRBY', key, now_ms, 1)
redis.call('EXPIRE', key, math.ceil(window_ms / 1000) + 1)</p><p>if current_count > max_count then
return 0
end
return 1- 调用时传入：
KEYS[1]（如"rate:login:192.168.1.1"），ARGV[1]（窗口毫秒数，如 60000），ARGV[2]（最大请求数），ARGV[3]（当前毫秒时间戳） - 注意：脚本里没用
TIME命令，避免主从时钟不一致；客户端必须传准确时间戳 - EXPIRE 时间要略大于窗口长度（+1 秒），防止 key 过早消失
Go 客户端调用要点（github.com/go-redis/redis/v9）
别手写 Eval 字符串拼接，用 script.Load 预加载，再 Run 执行。错误处理重点抓 redis.Nil（脚本返回 nil，通常因 key 不存在且未触发 HINCRBY）和 Lua 返回值类型。
- 加载脚本：
script := redis.NewScript(luaContent) - 执行时传参：
result, err := script.Run(ctx, rdb, []string{key}, windowMs, maxCount, time.Now().UnixMilli()).Result() - 判断结果：
if result == int64(1) { /* 放行 */ } else { /* 拒绝 */ } - 别忽略
ctx超时——Lua 脚本卡住会导致整个 Redis 连接阻塞
Key 设计与内存膨胀风险
Key 必须带业务维度（如用户 ID、IP、API 路径），但不能无限制增长。滑动窗口的 HASH 会持续写新字段，如果窗口粒度太细（比如 10ms），或服务长期运行，HKEYS 扫描成本会上升。
- 建议窗口粒度 ≥ 100ms，上限控制在 1000 个字段以内
- 定期用
SCAN+HLEN监控 key 大小，超过阈值（如 500）就告警 - 避免用时间戳字符串做 key 主体（如
"rate:20240501"），应把时间戳作为 HASH 的 field，主体用稳定标识
滑动窗口的精度和资源消耗是硬币两面，选 1 秒窗口还是 100 毫秒，得看你的错误预算和 Redis 内存水位——这点容易被压测时忽略。
