redis.pcall 不是更安全，而是将错误转为可控分支；误用会导致内存溢出或掩盖问题。它返回错误表但不自动释放内存，需显式判错并置 nil；核心操作应优先用 redis.call() 保证强一致性，非关键读取才用 pcall 并严格校验。
redis.pcall 不是“更安全”，而是把错误从崩溃变成可控分支；用错地方反而更容易内存溢出或掩盖问题。
redis.call() 一错就停，脚本直接中断
调用 redis.call() 时，只要命令失败（比如 HGET 查一个不存在的 hash、INCR 对字符串类型 key 操作），整个脚本立刻终止，返回 ERR 错误。客户端收到的是裸异常，没机会做任何兜底。
- 适合强一致性主流程：如扣库存前先
EXISTS校验，确认无误再DECR，错就该全退 - 不适合读取辅助数据：比如顺手查个日志计数器，它挂了不该拖垮主逻辑
- 常见误用：在循环里反复
redis.call("GET", key)，某个 key 不存在 → 脚本中途退出 → 后续 key 全部漏处理
redis.pcall() 返回错误表，但不释放内存
redis.pcall() 遇错不抛，而是返回形如 {err = "ERR no such key"} 的 table。这让你能写 if res.err then ... end 分支处理，但代价是——这个 table 会一直留在 Lua 栈上，直到脚本执行完才被 Redis 批量 GC。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 循环中反复调用
redis.pcall()且不设res = nil→ 大量错误表堆积 → 内存占用飙升，可能触发 OOM - 必须显式判断：
local res = redis.pcall("GET", k); if not res.err then val = res end，不能只调用不检查返回值 - 别用
pcall包裹所有调用：对核心 key 仍该用call，否则“假装成功”导致状态错乱（比如误以为SET成功了）
真正安全的写法：按场景选 + 主动清理 + 显式校验
安全不来自函数名，而来自你是否清楚每个调用的失败含义和业务容忍度。
- 读非关键 key（统计、缓存探针）→
redis.pcall()+ 立即判 err + 设res = nil - 写主业务数据（订单、余额）→
redis.call()+ 前置检查（EXISTS/HEXISTS）+ 不依赖“默认值” - 遇到
nil别直接当“key 不存在”：可能是类型错、网络抖动、脚本超时中断，得结合上下文判断 - 所有
pcall结果必须检查type(res) == "table"和res.err，不能只看res ~= nil
最易被忽略的一点：Redis 不区分“命令不存在”和“key 不存在”的错误信息，redis.pcall("FOO", "x") 和 redis.pcall("GET", "missing") 都返回类似 {err="ERR ..."}，靠字符串匹配判断类型既脆弱又难维护——真要区分，得在脚本里加命令白名单或提前用 EXISTS 探路。
