正确做法是用 EVAL 执行 Lua 脚本保证原子性，结合 PTTL 和 TIME 实现毫秒级令牌补充，避免客户端时间依赖；Redis 6.2+ 可用 CL.THROTTLE 简化实现。
用 INCR + EXPIRE 模拟令牌桶，但要注意原子性问题
Redis 本身没有原生令牌桶命令，得靠多个命令组合实现。最常见写法是先 INCR 计数器，再 EXPIRE 设置过期时间——但这不是原子操作，高并发下可能漏设过期，导致计数器永久残留。
正确做法是用 EVAL 执行 Lua 脚本，把“增、判、设过期”锁在一次请求里。比如：当前令牌数不足时，不增加；足够则减一并保持 TTL 不变。
- 脚本里用
redis.call("INCR", KEYS[1])获取新值，再用redis.call("TTL", KEYS[1])查剩余时间 - 首次访问需同时设初始值和 TTL，推荐用
SET key 1 EX 60 NX（注意NX防覆盖） - 别依赖客户端时间判断窗口，所有逻辑必须在 Redis 端完成，否则时钟不同步会出错
PTTL 和 TTL 的区别影响重置逻辑
令牌桶需要“定期补充”，但 Redis 不支持定时回调。实际做法是每次请求时，根据上次更新时间和当前时间差，算出应补多少令牌。这时必须用 PTTL（毫秒级），而不是 TTL（秒级），否则在 1 秒内多次请求会误判为“没过期”，导致补发失败。
例如限流窗口 100ms，补速率 10 token/s，那每 100ms 补 1 个。如果只查 TTL，两次请求间隔 50ms 但落在同一秒内，TTL 返回值不变，就无法触发补充。
- 用
PTTL获取精确剩余毫秒数，再结合TIME或客户端传入时间戳推算流逝时间 - 补令牌后要重设
PEXPIRE，不能只改 value，否则 TTL 会归零或错乱 - 注意 Lua 脚本里
TIME返回的是秒+微秒数组，要自己转成毫秒做计算
用 CL.THROTTLE（Redis 6.2+）更省事，但得确认服务端版本
Redis 6.2 加了 CL.THROTTLE 命令，底层就是令牌桶，直接返回 [是否允许, 当前余量, 下次允许时间戳, 总容量, 重试等待毫秒] 五个值。不用手写 Lua，也不用担心竞态。
但它不是默认开启的，有些云厂商 Redis 实例（比如阿里云早期版本）没开 redis-cell 模块，调用会报 (error) ERR unknown command `CL.THROTTLE`。
- 先执行
MODULE LIST看输出里有没有name:redis-cell - 参数顺序是
CL.THROTTLE key max_burst count per_msec，注意单位是毫秒，不是秒 - 返回数组第 4 项是“被拒绝后还要等多少毫秒”，可直接塞给客户端做
Retry-After头
客户端时间不准会导致令牌计算漂移
很多实现让客户端传“上次访问时间戳”进来，由 Lua 脚本算间隔。这很危险——手机 App、浏览器、NTP 不稳的服务器，时间可能快慢几秒。结果就是同一用户在不同设备上触发限流策略不一致，甚至出现“明明刚用过，却说还能用”的情况。
真正可靠的做法是：只存最后一次成功操作的 Redis 服务端时间（用 TIME 命令获取），所有时间差都在 Lua 里用两次 TIME 结果相减得出。
- 别在客户端算“now - last_time”，而是在 Lua 里做
current_time - stored_time - 存储的时间戳必须是
TIME返回的整数对（秒+微秒），不要转成字符串或 JS Date - 如果必须兼容老版本 Redis（LPUSH+
LLEN+EXPIRE），也别信客户端时间
事情说清了就结束
