直接用 redis.Incr 做限流会出错，因为 INCR 不带过期逻辑，INCR 与 EXPIRE 分两步执行在高并发下存在竞态，导致计数器未设 TTL 或重复计数；唯一可靠方案是用 Lua 脚本原子封装 INCR 和 EXPIRE。
为什么直接用 redis.Incr 做限流会出错
因为 INCR 本身不带过期逻辑，如果只调用 redis.Incr 再手动 Expire，在高并发下极易出现「计数器已增但过期没设上」的情况，导致限流失效。更糟的是，多个客户端可能同时读到旧值、各自 +1、再写回，造成漏判。
正确做法是把「原子递增 + 设置过期」合并成一条命令。Redis 6.2+ 支持 INCR 的 EX 选项，但 Go 客户端（如 github.com/redis/go-redis）尚未原生封装该语法，得手写 Eval 脚本。
- 用
INCR+EXPIRE两步走 → 不安全，竞态明显 - 用
SET key 1 EX 60 NX判断是否新建 → 只能用于首次请求，无法累计计数 - 用 Lua 脚本封装
INCR和EXPIRE原子操作 → 唯一可靠方案
用 Lua 脚本实现原子限流的最小可行代码
核心逻辑：先 INCR，若返回值为 1（即刚创建），立刻 EXPIRE；否则不管。这样既避免重复设过期，又保证所有 key 都有 TTL。
const luaScript = `
if redis.call("INCR", KEYS[1]) == 1 then
redis.call("EXPIRE", KEYS[1], ARGV[1])
end
return tonumber(redis.call("GET", KEYS[1]))
`Go 中调用：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
script := redis.NewScript(luaScript)
count, err := script.Run(ctx, rdb, []string{"rate:login:192.168.1.100"}, "60").Int64()
if err != nil {
// 处理连接或脚本错误
}
if count > 10 {
return errors.New("too many requests")
}-
KEYS[1]是限流 key，建议包含业务维度（如用户 ID、IP、接口路径） -
ARGV[1]是 TTL 秒数，必须传字符串，Lua 中用tonumber()转换 - 脚本返回当前计数值，方便上层判断是否超限
- 注意
Run返回的是Cmd，需用.Int64()提取结果，否则 panic
如何支持滑动窗口（比如每分钟最多 100 次，不是整点重置）
固定窗口（上面的方案）简单但有临界问题：用户在窗口末尾发 100 次，下一秒又发 100 次，实际 2 秒内就 200 次。滑动窗口需要记录每次请求时间戳，通常用 Redis 的 ZSET 实现。
思路：以请求时间为 score 存入 ZSET，每次先 ZREMRANGEBYSCORE 清理过期项，再 ZCARD 查数量，最后 ZADD 新条目。这三步也必须原子化，同样靠 Lua：
const slidingWindowScript = `
local key = KEYS[1]
local window = tonumber(ARGV[1])
local now = tonumber(ARGV[2])
redis.call("ZREMRANGEBYSCORE", key, 0, now - window)
local count = redis.call("ZCARD", key)
if count < tonumber(ARGV[3]) then
redis.call("ZADD", key, now, now .. ":" .. ARGV[4])
redis.call("EXPIRE", key, window + 1)
end
return count
`-
ARGV[2]必须由 Go 层传入time.Now().Unix()，不能在 Lua 里用redis.call("TIME")（精度低且集群模式不可靠） -
ARGV[4]是唯一标识（如请求 ID 或毫秒级时间戳），防止同一秒内多次请求被 ZSET 去重 -
EXPIRE设为window + 1秒，确保 key 在窗口结束后至少存活 1 秒，避免提前消失 - 性能比计数器差，QPS 过万时需压测评估延迟
生产环境必须检查的三个配置点
限流一旦上线就直接影响用户体验，以下三点不验证清楚，上线等于埋雷：
- Redis 连接池大小：默认
MaxIdleConns=10，高并发下会阻塞，建议设为 QPS 的 2–3 倍（如 500 QPS 至少配 1000） - 脚本缓存：
redis.NewScript每次都注册新 SHA1，高频调用会挤占 Redis script cache，应全局复用一个*redis.Script实例 - key 过期策略：确认 Redis 配置了
maxmemory-policy=volatile-lru或类似策略，否则内存满时可能误删限流 key
滑动窗口的 ZSET key 如果不加 EXPIRE，长期积累会撑爆内存；而固定窗口的 string key 即使没设过期，只要用的是 Lua 原子脚本，也能保证 TTL 正确 —— 这个细节很容易被忽略。
