Redis Lua脚本中直接用redis.call("GET", KEYS[1])会因key不存在而报ERR no such key并中断执行；必须先用redis.call("EXISTS", KEYS[1]) == 1显式判断存在性，再执行读取操作，以保障原子性和脚本安全。
Redis Lua脚本里直接用 redis.call("GET", KEYS[1]) 报 ERR no such key
这是最典型的 Lua 脚本崩溃场景：脚本里没做存在性检查，就直接对 KEYS[1] 执行 GET、HGETALL、LRANGE 等读取命令，一旦 key 不存在，Redis 会立刻中断脚本并抛出 ERR no such key —— 这不是返回值，是真正中断执行的错误。
根本原因在于，Redis 的原子性只保证“脚本内所有命令按序执行”，不保证“命令本身能成功”。EXISTS 是安全的（永远返回 0 或 1），但 GET 不是。
- 别在 Lua 脚本里写
local val = redis.call("GET", KEYS[1])后直接用val做逻辑判断 - 必须先用
redis.call("EXISTS", KEYS[1]) == 1判断，再决定是否继续调用读取命令 - 如果业务允许空值逻辑（比如缓存穿透防护），可统一返回预设默认值，避免上层反复判空
EVAL 执行前用客户端 EXISTS 检查再决定是否发脚本？
不行。这不是“多此一举”，而是破坏原子性的典型做法 —— 客户端先 EXISTS，再 EVAL，中间存在竞态窗口：key 可能在两次请求之间被删掉或过期，导致脚本仍报错。
真正安全的做法是把 EXISTS 放进 Lua 脚本内部，和后续操作一起原子执行。
- 错误示范：
if client.exists("user:123") { client.eval(luaScript, 1, "user:123") } - 正确写法：Lua 脚本开头就写
if redis.call("EXISTS", KEYS[1]) == 0 then return nil end - 更稳妥的写法是把整个业务逻辑封装进脚本，例如“存在则返回值，否则返回空字符串或特定标记”，由脚本统一控制返回形态
用 pcall 包裹 redis.call 能捕获 ERR no such key 吗？
不能。Redis 的 Lua 环境不支持标准 Lua 的 pcall 或 xpcall，调用失败会直接终止脚本，不会进入异常处理分支。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
你写的 pcall(function() redis.call("GET", KEYS[1]) end) 在 Redis 中会报 Lua script attempted to access a non-existent global variable 'pcall' —— 因为 Redis 的 Lua 沙箱禁用了这些函数。
- Redis Lua 只暴露了
redis.call和redis.pcall（注意是redis.pcall，不是全局pcall） -
redis.pcall("GET", KEYS[1])确实可以捕获错误，返回{err = "ERR no such key"}这样的 table，但代价是失去原子语义：后续命令仍会执行，可能造成状态不一致 - 所以优先选
EXISTS显式判断，而不是靠redis.pcall补救
批量操作多个 key 时，怎么高效判断存在性？
别对每个 key 单独 EXISTS，更别用 KEYS 或 SCAN —— 前者阻塞，后者非原子，且无法在脚本中用。
正确方式是把所有待查 key 放进 KEYS 数组，在脚本里循环检查：
for i = 1, #KEYS do
if redis.call("EXISTS", KEYS[i]) == 0 then
return "key missing: " .. KEYS[i]
end
end
-- 后续操作
但要注意：如果 key 数量大、且多数不存在，提前退出比全量检查更省资源；如果必须全量处理（比如批量 setnx），那就用 redis.call("EXISTS", ...) 逐个判断，别图省事用 redis.pcall。
最容易被忽略的一点：即使脚本里写了 EXISTS，也要确认客户端传入的 KEYS 数组不为空，否则 KEYS[1] 会触发 ERR index out of bounds —— 这类低级错误在线上常被漏测。
