redis.call()比redis.pcall()更易触发oom，因其失败即终止，而pcall()返回的错误表常驻lua栈且累积不释放，redis lua引擎仅在脚本退出时批量gc。
为什么 redis.call() 比 redis.pcall() 更容易触发 OOM？
因为 redis.call() 在命令失败时直接抛出错误并中断脚本，而 redis.pcall() 会捕获错误、返回状态表——这个表本身会常驻在 Lua 栈里，且如果反复调用（比如在循环中没清理返回值），会累积大量未释放的 table 对象。Redis 的内置 Lua 解释器不支持 GC 主动触发，只能靠脚本退出时批量回收，所以“看似安全”的容错写法反而更耗内存。
- 避免在循环里用
redis.pcall("GET", key)并把结果存进局部变量，尤其当key数量大时 - 真要容错，用
local res = redis.pcall(...); if type(res) == "table" and res.err then ... end，之后立即设res = nil -
redis.call()不是万能解药：它失败直接终止，可能让部分 key 被漏处理，得看业务是否允许“全量失败”
如何限制 Lua 脚本里创建的临时数据大小？
Redis 不提供对 Lua 堆内存的硬性配额，但可以通过控制数据结构规模和提前截断来规避爆内存。核心思路是：不让脚本生成超长字符串、超大 table 或嵌套过深的对象。
- 用
string.sub()截断拼接结果，比如日志类字段别直接table.concat(big_list)，先检查#big_list - 遍历集合前加长度判断：
if #keys > 5000 then return {err="too many keys"} end - 避免用
table.insert()往大 table 里无节制追加；改用预分配：local arr = {} for i=1,100 do arr[i] = ... end
evalsha 复用脚本真的能省内存吗？
能，但只省“脚本解析开销”，不省运行时 Lua 堆内存。Redis 启动后首次 EVAL 会编译并缓存字节码，后续 EVALSHA 跳过词法/语法分析，减少 CPU 和短暂内存峰值。但每次执行仍会新建 Lua 状态机，所有局部变量、中间 table 都重新分配。
- 高频小脚本（如原子计数）务必用
EVALSHA+ 客户端缓存 sha1 - 不要以为复用脚本就能无视内存检查——
EVALSHA执行时照样可能 OOM - 若脚本里用了
redis.sha1hex动态算 hash，等于放弃缓存优势，还多一次计算开销
遇到 (error) OOM command not allowed when used memory > 'maxmemory' 怎么快速定位？
这个错误不是 Lua 报的，是 Redis 在执行前检查自身内存水位时拒绝执行——说明脚本虽小，但触发了大量 key 加载或结果膨胀，把 Redis 推过了 maxmemory 阈值。
- 先查
INFO memory里的used_memory_peak和mem_fragmentation_ratio，确认是不是碎片或峰值残留 - 用
redis-cli --ldb --eval script.lua开启调试模式，在关键位置插redis.log(redis.LOG_WARNING, "size:", #my_table)观察增长点 - 重点盯
KEYS参数传入数量、redis.call("HGETALL", key)类全量读取、以及字符串拼接循环
最麻烦的情况是脚本逻辑正常，但并发高时多个实例同时加载大 value —— 这时候得靠限流或拆分 keys，而不是改 Lua。
