redis lua脚本中可用标准lua 5.1的if-else、elseif语法，但须注意：所有分支必须在服务端原子执行；避免将命令返回值（如nil/""）误当布尔判断，应显式检查（如val ~= nil and val ~= ""）。
Redis Lua脚本里怎么写 if-else 分支？
Redis 使用的是标准 Lua 5.1，if、elseif、else 都能直接用，但要注意：所有分支逻辑必须在服务端原子执行，不能依赖客户端状态。常见错误是误把 Redis 命令返回值当布尔用——比如 redis.call("GET", "key") 返回 nil 时，Lua 中 nil 是 falsy，但空字符串 "" 是 truthy，这点容易踩坑。
实操建议：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
-
if判断前先显式检查返回值是否为nil，例如：local val = redis.call("GET", "key"); if val ~= nil and val ~= "" then ... end - 避免用
not val判空，因为val == false在 Redis Lua 中几乎不会出现，但nil和""行为不同 - 分支中调用的 Redis 命令（如
redis.call("INCR", "counter")）仍受 EVAL 原子性保护，无需额外加锁
for 和 while 循环在 Redis Lua 中安全吗？
可以写，但必须确保循环次数可控。Redis 对单个脚本执行时间有硬限制（默认 5 秒），超时会触发 BUSY Redis is busy running a script 错误。更危险的是，无限循环或迭代过深会阻塞整个 Redis 实例。
实操建议：
- 禁用
while true do这类无退出条件的写法；用for i = 1, #list do更安全，前提是list长度可预估（比如来自redis.call("LRANGE", ...)的结果） - 若需遍历大量 key，优先考虑用 Redis 原生命令（如
SCAN+ 客户端分页），而不是在 Lua 里KEYS *后 for 循环——后者会阻塞且不推荐用于生产 - 循环内避免嵌套调用耗时命令，比如在 for 中反复
redis.call("HGETALL", key)，应尽量批量操作或提前聚合
如何在 Lua 脚本里处理 Redis 命令失败？
redis.call() 遇错会直接抛出异常，中断脚本；而 redis.pcall() 捕获错误并返回 {err = "..."} 表结构，适合做条件恢复。很多人混淆两者，导致脚本意外终止。
实操建议：
- 对非关键命令（如记录日志用的
LPUSH log:xxx）用redis.pcall()，避免因日志失败拖垮主逻辑 - 对核心命令（如扣减库存的
DECRBY stock:item1 1）必须用redis.call()，让失败立刻暴露，而不是静默忽略 - 不要在
pcall后写if type(res) == "table" and res.err then——更简洁写法是：local res = redis.pcall("GET", "key"); if res.err then return res.err end
为什么脚本里不能用 Lua 的 os.time() 或 math.random()？
Redis 为保证脚本在主从、集群间确定性重放，禁用了所有非纯函数：包括 os.time()、math.random()、io.* 等。调用会直接报错 @user_script: N: attempt to call a nil value (field 'time')。
实操建议：
- 需要时间戳时，用
redis.call("TIME")（返回秒+微秒数组）或传入客户端时间作为ARGV参数 - 需要随机数时，用
math.randomseed(tonumber(ARGV[1]) or 1)+math.random()，但种子必须由客户端传入且固定，否则主从结果不一致 - 任何依赖系统状态的 Lua 标准库函数都不可用，只信任
redis.*和纯 Lua 逻辑（字符串/表/数学运算）
redis.call 发生，所有外部输入只能来自 KEYS 和 ARGV。一旦跳出这个模型，比如试图读文件、开线程、调系统时间，就注定失败。
