滑动窗口限流不能仅用redis incr+expire，因二者非原子操作，易导致key永久存在或丢失、窗口错乱；必须用lua脚本保证计数与过期设置的原子性，并统一使用redis服务端时间戳。
滑动窗口限流为什么不能只用 Redis INCR + EXPIRE
因为 INCR 和 EXPIRE 是两个独立命令，中间可能被中断（如 Redis 连接断开、服务崩溃），导致 key 永久存在或永久丢失，窗口边界错乱。真实场景下，必须保证「计数 + 过期时间设置」原子性。
- 推荐用
EVAL执行 Lua 脚本，Redis 保证脚本内操作原子执行 - 不要在 Go 层做“先查再判再增”逻辑——竞态无法避免，尤其多实例部署时
- 注意 Lua 脚本里不能用
redis.call("EXPIRE", ...)对已存在的 key 重复设过期：Redis 6.2+ 才支持EXPIRE返回值判断，老版本得用PEXPIREAT算毫秒级绝对过期时间
Go 里调用 Lua 实现滑动窗口的最小可行写法
核心是把窗口切分成多个时间桶（比如 1 秒 1 桶），用一个有序集合（ZSET）存每个请求的时间戳，再用 ZREMRANGEBYSCORE 清理过期桶。但更轻量的做法是直接用 list + LTRIM，适合精度要求不高的场景（如 1 分钟窗口，每秒 1 桶）。
- 用
LPUSH+LTRIM维护一个带时间戳的 list，长度限制为窗口总桶数 × 每桶最大请求数 - 但 list 不支持按时间范围剔除，所以更稳的是
ZSET：member 用唯一 ID（如req_id:timestamp），score 存 Unix 时间戳 - Go 中用
redis.Client.Eval调用脚本，传入key、window_seconds、max_requests三个参数 - 脚本返回 1 表示放行，0 表示拒绝；别忽略返回值类型转换：
int64而不是bool
local key = KEYS[1]
local window = tonumber(ARGV[1])
local max = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local zset = redis.call("ZRANGEBYSCORE", key, 0, now - window)
local count = #zset
if count >= max then
return 0
end
redis.call("ZADD", key, now, ARGV[4])
redis.call("EXPIRE", key, window + 1)
return 1多实例部署时，时间不同步会让滑动窗口失效
如果各机器系统时间差超过窗口粒度（比如窗口是 1 秒，但 A 机比 B 机快 1.2 秒），B 机认为刚进来的请求已过期，A 机却还在计数，结果就是实际 QPS 超出预期。
- 强制所有服务同步 NTP，误差控制在 100ms 内（
ntpq -p检查 offset） - 不要用本地
time.Now().Unix()当 score，改用 Redis 的TIME命令返回服务端时间（Lua 里用redis.call("TIME")获取） - 如果业务对精度要求不高，可降级为固定窗口（
INCR+EXPIRE），但要注意它会放大峰值流量（窗口切换瞬间允许双倍请求）
Redis 内存增长不可控？得清理过期 zset 成员
ZADD 不会自动删旧数据，靠脚本里的 ZRANGEBYSCORE 只读不删，长期运行会导致 key 膨胀。必须主动清理。
立即学习“go语言免费学习笔记（深入）”；
- 在 Lua 脚本末尾加
redis.call("ZREMRANGEBYSCORE", key, 0, now - window)，和判断逻辑共用同一时间点 - 别用
ZREMRANGEBYRANK—— rank 不代表时间顺序，zset 按 score 排序，rank 是位置索引 - 如果窗口很长（如 24 小时）、QPS 很高，单次
ZREMRANGEBYSCORE可能阻塞 Redis，考虑分批删（但 Lua 不支持循环 sleep，得在 Go 层拆成多次 EVAL）
时间戳必须统一来源，窗口逻辑才可靠。哪怕 Redis 集群有从节点，也只跟主节点交互，别让客户端自己拼时间。
