redis集群下lua脚本必须所有keys同slot，否则报crossslot错误；解决方法是用{}哈希标签（如user:{123}）强制路由，且keys须显式传入、不可脚本内拼接，聚合操作优先用原生命令或客户端处理。
Redis Lua脚本不能做多key跨slot聚合
集群模式下，所有 KEYS 必须落在同一个 slot，否则报错 CROSSSLOT Keys in request don't hash to the same slot。比如你想对 user:123、profile:123、order:123 三个 key 做字段合并计算，但它们 hash 后大概率不在同一 slot —— 脚本直接失败。
常见错误现象：本地单机测试正常，一上集群就报 CROSSSLOT 错误；或用 redis-cli --cluster 模拟时发现 key 分布不均。
- 解决方案：提前用
{}标记强制路由，例如把 key 写成user:{123}、profile:{123}，确保哈希一致 - 更稳妥的做法：客户端预聚合，只把最终结果写入一个 key，Lua 只读这个 key
- 别指望用
redis.call('GET', 'user:123')+redis.call('GET', 'profile:123')绕过 —— 集群会拒绝执行
脚本里遍历 SCAN 结果等于主动卡死 Redis
用 SCAN 在 Lua 中循环过滤，再做累加或拼接，本质是把 O(n) 计算压到主线程。哪怕只扫 1 万 key，脚本执行期间整个 Redis 无法响应任何请求，包括心跳、AOF 刷盘、键过期。
典型错误写法：for i = 1, #res, 2 do if res[i+1] == 'vip' then sum = sum + tonumber(res[i+2]) end —— 这里 res 是 redis.call('SCAN', ...) 返回值，但 #res 会报错，且循环本身已不可控。
- 正确做法：用客户端分页 SCAN，每次只取 100 条，处理完再发下一批
- 如果真要服务端聚合，优先用原生命令，比如
SINTER、ZUNIONSTORE，它们内部用 C 实现，不走 Lua 解释器 - 务必设置
lua-time-limit（默认 5 秒），否则卡死可能持续到超时
redis.call() 在循环中调用开销巨大
每次 redis.call() 都触发完整命令生命周期：解析参数、ACL 检查、键存在性校验、实际执行。哪怕只是反复读同一个 key，三次调用 ≈ 三次网络往返的开销（只是省了 TCP 层）。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
错误模式很隐蔽：比如在 if 分支里读一次 redis.call('GET', KEYS[1])，else 里又读一次，最后返回前再读一次 —— 实际做了三次相同操作。
- 必须缓存：用
local val = redis.call('GET', KEYS[1])，后续全用val - 批量读优先用
MGET或HGETALL，别写 for 循环调redis.call('HGET', key, field) -
table.unpack(ARGV)在参数超 1000 个时可能栈溢出，生产环境建议客户端分批传参
返回值不是原生 Lua table，直接 # 取长度会崩溃
redis.call() 返回的是代理对象，不是真实 table。写 #res 或 for i=1,#res do 会触发 (error) ERR Error running script (call to f_): @user_script:3: attempt to get length of a userdata value。
这问题常出现在 GEOSEARCH 或 HMGET 返回结果后，想用 Lua 做排序、分页、去重等操作 —— 全部失效。
- 安全遍历方式：用
res[1]、res[2]显式索引，或用table.unpack(res)展开（注意长度限制） - 排序、分页、复杂过滤逻辑一律交给客户端：Python 的
sorted()、Go 的sort.Slice()、Java 的Stream，它们不抢主线程，还能限流和打点 - 别在脚本里实现
table.slice()分页，数据量 > 500 就大概率超时
真正容易被忽略的点是：Lua 脚本的“原子性”和“高性能”只在轻量、确定性、短耗时场景成立；一旦涉及任意规模的遍历、跨 key 关联、动态条件过滤，它就成了性能定时炸弹——不是慢，而是让整个 Redis 实例暂时失能。
