redis.call()出错立即终止脚本，适合主流程强一致性操作；redis.pcall()捕获错误返回表，需手动判err并置nil防内存泄漏。
redis.call() 一错就停，适合主流程强一致性操作
调用 redis.call() 时，只要命令执行失败（比如对字符串类型 key 执行 INCR、用 HGET 查一个不存在的 hash），整个 Lua 脚本立刻终止，Redis 直接返回 ERR 错误。客户端收不到任何中间结果，也没机会做兜底逻辑。
这反而是优点：它强制你在关键路径上「不侥幸」。例如扣库存前必须先 EXISTS 校验，确认无误再 DECR；一旦出错，整个事务干净回滚，状态不会错乱。
- 别在循环里盲目用
redis.call("GET", k)：某个k不存在 → 脚本中断 → 后续所有 key 全部漏处理 - 写订单、余额、库存等核心数据，优先选
redis.call()，配合前置检查（HEXISTS、TYPE等） - 硬编码 key/val 在脚本里（如
"user:1001"）会破坏脚本缓存，应统一走KEYS[1]和ARGV[1]
redis.pcall() 返回错误表，但不自动释放内存
redis.pcall() 遇错不抛，而是返回形如 {err = "ERR no such key"} 的 Lua table。你可以写 if res.err then ... end 分支处理，但代价是——这个 table 会一直留在 Lua 栈上，直到脚本执行完才由 Redis 批量 GC。
这意味着：不显式清理，错误积多就会内存暴涨，甚至触发 OOM。
- 必须显式判断：
local res = redis.pcall("GET", k); if not res.err then val = res，不能只调用不检查 - 每次判错后建议立即设
res = nil，尤其在 for 循环或批量读取场景下 - 别用
pcall包裹所有调用：对主业务 key 仍用call，否则“假装成功”会导致状态错乱（比如误以为SET成功了）
怎么区分错误类型？别靠字符串匹配 err
Redis 不区分「命令不存在」和「key 不存在」的错误信息：redis.pcall("FOO", "x") 和 redis.pcall("GET", "missing") 都返回类似 {err="ERR "} 的结构。靠 string.match(res.err, "no such key") 判断既脆弱又难维护。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真要区分错误语义，得在脚本里提前探路：
- 读非关键 key（如统计计数器、缓存探针）前，先用
EXISTS或TYPE做轻量校验 - 对高风险命令（如
INCR、HINCRBY）加白名单保护，或封装成带类型断言的 helper 函数 - 所有
pcall结果必须检查type(res) == "table"和res.err，不能只看res ~= nil
安全不是选函数，而是清楚每个调用的失败含义
所谓“更安全”，从来不是 pcall 自带的属性。它只是把崩溃变成分支，而分支是否可靠，取决于你是否理解该操作失败时的业务容忍度。
读日志计数器挂了，不影响下单；但扣库存失败还继续发券，就是灾难。这种差异无法靠函数名自动识别。
- 非关键读取 →
redis.pcall()+ 立即判err+ 设res = nil - 主业务写入 →
redis.call()+ 前置检查 + 拒绝默认值兜底 - 遇到
nil别直接当“key 不存在”：可能是类型错、网络抖动、脚本超时中断，得结合上下文判断
最容易被忽略的一点：Lua 栈上残留的错误表不会被单独 GC，脚本越长、错误越多、循环越深，内存压力越隐蔽。不清理，迟早 OOM。
