“先查后incr”必出错，因其非原子操作：Java中get、判断、incr三步存在竞态窗口，多请求可同时读旧值并写入，导致计数翻倍或漏限；而Lua脚本将判断、计数、过期设置全置于Redis单线程内执行，天然强一致。
为什么“先查后 incr”一定会出错
因为这不是原子操作。常见写法是 Java 里先 stringRedisTemplate.opsForValue().get("counter")，再 if 判断，最后 incr("counter")。这三步之间有竞态窗口：多个请求可能同时读到旧值、同时判定未超限、同时写入，最终计数翻倍或漏限。
Redis 单命令（如 INCR）本身原子，但跨命令的逻辑判断不在 Redis 控制范围内。网络延迟、JVM 调度、本地计算时间都会放大这个窗口。
-
GET和INCR是两次独立网络往返，中间可能插入任意其他客户端请求 -
MULTI/EXEC不能解决「读-算-写」逻辑竞争，它只保证命令序列不被穿插，不保证条件分支不出错 - 哪怕用
WATCH做乐观锁，失败重试在高并发下开销大，且业务逻辑仍暴露在客户端
必须把全部逻辑塞进 Lua 脚本里
Lua 脚本在 Redis 单线程中一次性执行完毕，中间不会被任何其他命令打断。只要判断、计数、过期设置全在脚本内完成，就天然强一致。
典型固定窗口限流脚本结构：
local key = KEYS[1]
local window = tonumber(ARGV[1]) -- 窗口秒数，如 60
local max = tonumber(ARGV[2]) -- 最大请求数，如 100
<p>local current = redis.call('INCR', key)
if current == 1 then
redis.call('EXPIRE', key, window)
end
if current > max then
return 0
else
return 1
end-
INCR自动初始化 key（不存在时从 0 开始），无需先GET -
EXPIRE只在首次INCR时设置，避免重复覆盖过期时间 - 返回值直接告诉调用方是否放行，Java 层不做任何判断
EVALSHA 与 SCRIPT LOAD 必须配对使用
生产环境绝不能每次都用 EVAL 发送完整脚本字符串。脚本太长会触发 ERR Error running script (call to f_): @user_script: N: user_script: too long 错误（Redis 默认限制 4KB）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
正确做法是提前注册脚本，后续只传哈希值：
- 首次调用前，必须执行
SCRIPT LOAD，例如：redis-cli --eval "script.lua" 1 counter或代码中显式调用redisTemplate.execute(RedisScript, ...)触发预热 - 之后统一用
EVALSHA，只传 40 字符 SHA1 值，大幅减少网络包体积和 Redis 解析开销 - 若忘记
SCRIPT LOAD，EVALSHA直接返回NOSCRIPT错误——这个错误极易被吞掉，导致限流完全失效
Redis Cluster 下多 key 的坑必须绕开
想用一个脚本同时操作多个计数器（比如按用户+接口双维度限流），在 Cluster 模式下会遇到 CROSSSLOT Keys in request don't hash to the same slot 报错。
这不是脚本问题，而是 Redis Cluster 架构硬约束：所有 KEYS 必须落在同一个 slot 才能被路由到同一节点执行。
- 解决方案只有两个：要么改用单节点 Redis（适合中小规模）；要么设计 key 名称让相关计数器强制落在同 slot，例如加固定前缀
{user:123}:api:/order，花括号内内容决定 slot 分配 - 别试图在脚本里用
redis.call('GET', 'other:key')跨 key 访问——Cluster 下照样报CROSSSLOT - 如果真要跨 slot 计数，只能拆成多次
EVALSHA调用，但此时「全局一致性」已无法保证，需接受最终一致性
真正难的不是写脚本，而是让整个链路没死角：脚本逻辑闭环、预热机制可靠、Cluster 分片可控、错误反馈可监控。少一个环节，一致性就塌一块。
