Redis Lua脚本出错时原子性中断且不回滚，redis.call()抛异常终止脚本，redis.pcall()捕获错误并允许继续执行；EVAL与EVALSHA执行期错误行为一致，但NOSCRIPT属解析阶段错误。
Redis Lua脚本执行报错时会怎样
Redis里Lua脚本一旦出错，整个脚本原子性中断，不回滚已执行的命令，但也不会继续执行后续语句。关键点是：redis.call() 抛异常会直接终止脚本，而 redis.pcall() 会捕获并返回错误表，脚本还能往下走。
- 常见错误现象：
(error) ERR Error running script (call to f_...): @user_script:5: user_script:5: attempt to call a nil value—— 这类错误说明脚本语法或调用逻辑有问题，Redis根本没进执行阶段 -
redis.call("GET", "missing_key")在 key 不存在时不会报错，但redis.call("HGET", "not_a_hash", "f")会触发(error) ERR Operation against a key holding the wrong kind of value - 所有错误都由 Redis 主动抛出，Lua 原生的
error()或未捕获异常也会被转为ERR响应
怎么安全地在Lua里做可能失败的操作
别依赖 redis.call() 做不确定操作，它像“硬断言”——失败就崩。真要容错，一律改用 redis.pcall()，它返回两元素数组：{ok, result_or_err}。
- 使用场景：比如批量查 hash 字段，某些 key 可能不是 hash 类型，用
redis.call("HGETALL", key)会中止；换成redis.pcall("HGETALL", key)就能判断再跳过 - 参数差异：两者签名完全一致，只是
pcall多一层保护壳，性能开销可忽略（实测单次调用差异在纳秒级） - 示例：
local res = redis.pcall("HGETALL", KEYS[1])<br>if type(res) == "table" and not res.err then<br> return res<br>else<br> return {err = "not a hash"}<br>end
EVAL 和 EVALSHA 的错误行为一致吗
一致。错误发生在脚本执行阶段，和你是用 SHA 还是源码提交无关。但要注意：如果脚本还没加载成功（比如第一次用 EVALSHA 传了个不存在的 SHA），Redis 直接返回 (error) NOSCRIPT No matching script. Please use EVAL. —— 这不属于“执行期间错误”，而是命令解析阶段失败。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 容易踩的坑：客户端缓存了 SHA 却没处理
NOSCRIPT，导致后续请求全挂；正确做法是捕获该错误后自动 fallback 到EVAL - 兼容性影响：Redis 2.6+ 都支持
pcall，但老版本（如 2.4）不支持 Lua，压根不能用；确认版本用INFO server看redis_version -
SCRIPT LOAD成功只代表语法合法，不保证运行时不报错——它甚至不校验KEYS或ARGV是否存在
事务、WATCH 和 Lua 错误的关系
Lua 脚本天然具备事务性，不需要 WATCH + MULTI/EXEC。但如果你在脚本里混用 redis.call("WATCH", ...)，Redis 会直接报错：(error) ERR WATCH inside Lua script is not allowed —— 这个限制很硬，连 pcall 都包不住。
- 为什么这样设计：Redis 的 WATCH 是 client 端状态，而 Lua 运行在 server 端，二者上下文隔离。强行桥接会导致语义混乱和竞态不可控
- 替代方案：想实现“检查-修改”逻辑，全放在 Lua 里用
EXISTS/GET判断，再决定是否SET；避免跨脚本依赖 - 性能提示：一个脚本里反复调用
redis.pcall()没问题，但别在循环里无节制调用redis.call()—— 一次崩，整批废
最易被忽略的一点：Lua 脚本里的错误不会触发 Redis 的慢日志（slowlog），除非它真跑超时。所以线上遇到诡异失败，别只盯 slowlog get，得去查客户端收到的原始 ERR 响应内容。
