EVAL需原子性保证竞态安全，因Redis将Lua脚本作为不可分割的单次操作执行，避免“先查后改”在高并发下的数据丢失；其原子性非源于Lua线程安全，而是Redis调度机制保障。
为什么 EVAL 要用原子性保证竞态安全
Redis 执行 Lua 脚本时，整个脚本在单个 Redis 实例的命令执行上下文中运行，不会被其他客户端请求打断。这不是“Lua 本身线程安全”，而是 Redis 主动把脚本当做一个不可分割的操作来调度——哪怕脚本里有 GET、INCR、SET 多步，也等价于一个原生命令。
常见错误是以为“先查再改”加个 WATCH 就够了，结果在高并发下仍丢数据：因为 WATCH + MULTI/EXEC 只对 key 级别乐观锁有效，一旦涉及多个 key 或条件判断（比如“余额 > 扣款额才扣”），失败重试成本高、逻辑难收敛；而 Lua 把判断和修改压进一次原子调用，没重试、没中间态。
- 脚本里不能调用阻塞命令（如
BLPOP），否则整个 Redis 实例卡住 -
EVAL的 script 参数必须是纯字符串，不能拼接用户输入，否则有注入风险（例如把用户传的 key 名直接插进 Lua 字符串） - Redis 7.0+ 支持
FCALL调用已注册函数，但首次仍需EVAL或EVALSHA加载，别漏掉缓存 hash 的同步逻辑
怎样写一个带条件扣减的 Lua 脚本（以库存扣减为例）
典型场景：扣库存前检查是否充足，充足则扣减并返回成功，否则返回失败。不能靠应用层两次 RTT（先 GET 再 DECR），网络延迟和并发会让判断失效。
正确做法是把“读-判-改”全放在 Lua 里，用 redis.call() 调用 Redis 命令：
if redis.call("GET", KEYS[1]) >= tonumber(ARGV[1]) then
redis.call("DECRBY", KEYS[1], ARGV[1])
return 1
else
return 0
end
调用时用：EVAL "..." 1 stock:123 5，其中 KEYS[1] 是 stock:123，ARGV[1] 是扣减量 5。
- 所有 key 必须显式传入
KEYS数组，Redis 集群模式下不支持脚本里硬编码 key（会路由失败） -
ARGV是字符串数组，数值要用tonumber()转，否则比较会出错（比如"10" > "2"在 Lua 里是 false） - 别在脚本里用
redis.pcall()捕获异常来“兜底”，它只捕获 Redis 命令错误，不解决逻辑错误；该返回什么业务码，由脚本自己决定
EVALSHA 缓存脚本后为什么还会报 NOSCRIPT
用 SCRIPT LOAD 加载脚本得到 SHA1 值，再用 EVALSHA 调用，本意是省去每次传大段字符串。但线上常遇到 (error) NOSCRIPT No matching script. Please use EVAL.。
根本原因是：Redis 实例重启后脚本缓存清空；主从切换时从库没同步到脚本（尤其在旧版 Redis 中 SCRIPT LOAD 不写 AOF）；集群中不同节点没各自加载。
- 别假设
SCRIPT LOAD一次就永久生效，每次调用EVALSHA前，必须做好 fallback 到EVAL的逻辑 - 应用启动时预加载常用脚本（用
SCRIPT LOAD），但得监听 Redis 连接断开事件，重连后重新加载 - 如果用连接池，注意不是每个连接都共享脚本缓存——Redis 脚本缓存是实例级的，只要连的是同一个 server 就行，不用每连接 load 一遍
本地开发调试 Lua 脚本的三个实际卡点
写完脚本不能直接扔生产，本地验证容易踩坑：语法没错，但语义或边界不对。
最有效的调试方式是用 redis-cli --eval 直连本地 Redis，配合 print() 输出中间值（注意：只有在 redis-cli 下 print() 才真输出到终端，生产环境用 redis.log() 会写日志但不可控）。
-
print()输出的内容不会作为脚本返回值，别指望靠它“看到结果”——返回值只能靠return - 测试时用
DEL清掉测试 key，但别在脚本里写redis.call("DEL", ...)来“清理现场”，这会污染真实逻辑 - 时间相关逻辑（比如“过期前才能操作”）慎用
redis.call("TIME")，它返回的是 Redis 服务器时间，可能和应用服务器有偏移，且无法 mock
真正难的不是写对语法，而是想清楚“这个脚本在极端并发下是否仍满足业务不变量”。比如扣库存成功后发消息，消息发送失败要不要回滚？Lua 本身做不到跨系统事务，这部分得靠补偿或最终一致性设计——脚本只管 Redis 内的原子性，别让它背不该背的责任。
