redis.pcall()是唯一安全的容错调用方式，因其总返回{ok, result_or_err}结构，可捕获错误并继续执行；而redis.call()遇类型错误或参数异常会直接终止脚本，且key不存在时返回false而非nil，易导致误判。
redis.pcall() 是唯一安全的容错调用方式，redis.call() 一旦失败就终止脚本，没有补救机会。
为什么不能用 redis.call() 做不确定操作
redis.call() 行为像硬断言：类型错误（如对 string 执行 HGET）、命令参数缺失、key 不存在但命令本身允许（如 GET）——只有前两类会中断脚本，而 key 不存在却返回 false，容易被误判为“成功”。更危险的是，它不提供错误上下文，你无法知道是键不存在、类型不对，还是网络临时异常（虽然 Lua 层不涉及网络，但语义上等效）。
常见踩坑写法：
-
if redis.call("HGET", KEYS[1], "field") == nil then ...→ 永远不成立，因为返回的是false，不是nil -
local res = redis.call("HGETALL", KEYS[1]); if type(res) == "table" then ...→ 若KEYS[1]是 string 类型，脚本直接报错退出，后续逻辑全丢
redis.pcall() 的返回结构与判断逻辑
redis.pcall() 总是返回一个两元素 table：{ok, result_or_err}。其中 ok 是布尔值，result_or_err 在成功时是原命令返回值，在失败时是错误字符串（形如 "ERR Operation against a key holding the wrong kind of value"）。
正确判断模式：
- 先检查
ok == false，再处理result_or_err - 不要用
type(result_or_err) == "string"判断失败 —— 成功时HGET也可能返回 string - 若需区分错误类型，可匹配
result_or_err是否包含特定子串，例如string.find(result_or_err, "WRONGTYPE")
示例：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
local res = redis.pcall("HGETALL", KEYS[1])
if not res.ok then
if string.find(res.result_or_err, "WRONGTYPE") then
return {err = "NOT_A_HASH", key = KEYS[1]}
else
return {err = "UNKNOWN_HGETALL_ERROR", detail = res.result_or_err}
end
else
return res.result_or_err
end
错误响应怎么让客户端真正“看到”
仅靠 return {err = "..."} 没用 —— Redis 不识别普通 table，客户端收到的是空或 null。必须用 return "ERR xxx" 格式，Redis 才会将其转为 RESP 错误（以 - 开头），客户端库（如 redis-py）才能抛出对应异常。
注意细节：
- 必须是字符串，且严格以
"ERR "（ERR 加空格）开头，大小写敏感 - 避免拼接不可信输入（如
ARGV[1]），先用string.match(v, "^%w+$")校验格式，防注入 - JSON 片段可嵌在错误字符串里，如
return 'ERR {"code":"MISSING_KEY","key":"'..KEYS[1]..'"}'，但双引号要手动转义 - 别用
redis.error_reply()—— 它只是内部函数，非公开 API，行为不稳定
脚本执行卡死时，script kill 为什么有时失效
当脚本已执行过至少一条写命令（如 redis.call("SET", ...)）后进入死循环，script kill 就会被拒绝 —— Redis 为防止数据不一致，禁止中断已产生副作用的脚本。
此时唯一办法是 shutdown nosave，但这是服务级中断。预防比补救重要：
- 所有循环必须带计数器或超时检查，例如
for i = 1, 100 do ... end - 避免在 Lua 中做复杂计算或遍历大集合，把数据拉到客户端处理
- 设好
lua-time-limit（默认 5000ms），超时后自动中断未完成的脚本
最易被忽略的一点：错误处理代码本身不能有 bug，否则 pcall 捕获后继续执行，反而掩盖了真实问题。建议在关键分支加 redis.log(redis.LOG_WARNING, "fallback triggered for "..KEYS[1]) 留痕。
