不能用 incr + expire 实现滑动窗口，因其为固定窗口、存在断连漏限/误限风险，且无法统计过去n秒内请求；必须用redis zset+lua脚本，并以服务端time命令获取毫秒级时间戳确保原子性与一致性。
直接用 INCR + EXPIRE 是固定窗口，不是滑动窗口；并发下还可能 panic 或漏限——必须用 Redis ZSET + Lua 脚本，且时间戳必须来自 Redis 服务端。
为什么不能用 INCR + EXPIRE 模拟滑动窗口
这是最常踩的坑：INCR 和 EXPIRE 是两个独立命令，中间一旦断连、超时或服务崩溃，就会导致 key 永久存在（漏限）或永久丢失（误限）。更关键的是，它根本无法回溯「过去 N 秒内」的请求数，只能统计「当前窗口内」——这叫固定窗口，有严重临界突刺问题。
滑动窗口的核心是「时间维度上的连续覆盖」，不是「周期性重置」。比如窗口设为 60 秒，第 59 秒和第 61 秒的请求必须被算进同一个逻辑窗口，而固定窗口会把它们分到两个完全隔离的桶里。
- 固定窗口：窗口边界硬切，
time.Now().Unix() / 60取整决定归属 - 滑动窗口：所有请求按真实时间戳存入 ZSET，每次查
ZCOUNT key (now-60) +inf - 多实例部署时，各机器本地时间差 > 窗口粒度（如 1 秒），结果直接失效
必须用 Redis 的 TIME 命令获取服务端时间戳
Go 层调 time.Now().Unix() 再传给 Lua，等于把客户端时间当权威——只要两台机器 NTP 同步误差超过窗口长度（比如窗口 1 秒，A 机快 1.2 秒），B 机就会把刚进来的请求判定为「已过期」，而 A 机还在计数，实际 QPS 翻倍也不自知。
Lua 脚本里必须调 redis.call("TIME")，它返回两个整数：[seconds, microseconds]，拼成毫秒级时间戳（seconds * 1000 + microseconds / 1000）最稳妥。
- 别用
redis.call("TIME")[1]直接当秒级时间——精度不够，1 秒内多次请求会撞 score - 别在 Go 层算好时间戳再传入
ARGV——失去原子性前提 - Redis 服务端时间必须开启 NTP 同步，且误差控制在 100ms 内（建议用
chrony）
Go 调用 Lua 实现限流的最小可靠写法
核心就三件事：清理过期项 → 统计当前窗口请求数 → 写入新请求。全部压进一个 Eval，返回值必须显式转 int64 判断。
示例 Lua 脚本（注意注释里的陷阱）：
local key = KEYS[1]
local window_ms = tonumber(ARGV[1]) -- 窗口长度，单位毫秒
local max_req = tonumber(ARGV[2])
local now_ms = tonumber(ARGV[3]) * 1000 + tonumber(ARGV[4]) / 1000 -- 拼毫秒时间戳
local window_start = now_ms - window_ms
<p>-- 1. 清理：删掉 window_start 之前的所有项（注意 -inf 不要加引号）
redis.call("ZREMRANGEBYSCORE", key, "-inf", window_start)</p><p>-- 2. 统计当前窗口请求数
local count = redis.call("ZCARD", key)</p><p>-- 3. 未超限才写入，避免无效 ZADD 拉高内存
if count </p><p>Go 层调用要点：</p>
rdb.Eval(ctx, script, []string{key}, windowMs, maxReq, seconds, micros, reqID).Int64()- 别用
EXPIRE，老版本 Redis 不支持对已存在 key 多次设过期；PEXPIREAT设绝对时间更稳 -
reqID必须全局唯一（如uuid.NewString()+"-"+strconv.FormatInt(nowMs,10)），防止同分值 member 被覆盖 - ZSET 不是为高频写优化的结构，单 key 请求量 > 5k/s 时要考虑分片（如 hash(key) % 16）
容易被忽略的存储与性能细节
ZSET 的内存开销比 list 高不少，但它是唯一能按时间范围精准清理+统计的数据结构。list + LPUSH/LRANGE 看似简单，但无法剔除「中间过期项」，只能靠 LTRIM 截断尾部，导致窗口漂移。
真正上线前必须确认：
- Redis 版本 ≥ 6.0（
PEXPIREAT在 2.6+ 就有，但高并发下旧版 ZSET 性能抖动明显） - key 生命周期靠
PEXPIREAT保障，不是靠业务层定时清理——否则 key 泄露风险极高 - 如果限流维度是用户 ID，key 命名建议用
sliding:uid:{id}，别带冒号以外的特殊字符，避免 Lua 解析出错 - 测试时一定要模拟时间跳变：用
redis-cli --raw -h x -p y EVAL "return redis.call('TIME')" 0看服务端时间是否和本地一致
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
