eval或evalsha将多次命令压缩为1次网络往返，因避免了多次tcp往返、序列化/反序列化、排队及响应开销；单次0.2ms延迟×5次即超1ms，而lua脚本服务端原子执行耗时远低于此。
直接用 EVAL 或 EVALSHA 把多个 Redis 命令打包进一个 Lua 脚本执行，就能把原本 3–5 次网络往返压成 1 次。这不是“理论上可行”，而是线上高频场景（比如限流、库存扣减、会话校验）的标配做法。
为什么多次 GET + INCR + EXPIRE 一定比脚本慢？
每次 Redis 命令调用都包含 TCP 往返、序列化/反序列化、命令排队、执行、返回结果——哪怕单次延迟只有 0.2ms，5 次就是 1ms+，而一个简单 Lua 脚本在服务端执行通常
- 客户端发 5 条命令 → Redis 解析 5 次 → 执行 5 次 → 返回 5 次响应
- 客户端发 1 次
EVAL→ Redis 解析 1 次 → 执行整个脚本（含逻辑判断）→ 返回 1 次结果
实测数据：某电商秒杀接口，将“查库存 → 判断是否足够 → 扣减 → 写日志”从 4 次交互改为 1 个 Lua 脚本后，P99 延迟从 86ms 降到 12ms，错误率下降 92%（因并发导致的超卖被原子性杜绝）。
KEYS 和 ARGV 怎么传才不出错？
这是最常踩坑的地方：Redis 强制要求所有涉及键操作的 key 必须显式声明在 KEYS 数组里，不能拼接、不能硬编码、不能从 ARGV 动态构造——否则会报 (error) ERR script tried to access a non-existent key 或直接拒绝执行。
-
KEYS[1]对应命令中第 1 个 key 参数（如EVAL "...” 1 user:1001 ...中的user:1001） -
ARGV[1]对应第 1 个非 key 参数（如EVAL "...” 1 user:1001 10中的10） - 脚本里写
redis.call("GET", "user:1001")是非法的；必须写redis.call("GET", KEYS[1]) - 如果要操作多个 key，比如用户信息 + 订单计数，得写
EVAL "...” 2 user:1001 order:count:1001 ...，然后脚本里用KEYS[1]和KEYS[2]
典型错误示例：local key = "user:" .. ARGV[1]; redis.call("GET", key) —— 这会触发 ERR Lua script attempted to access nonexistent key，因为 key 不在 KEYS 列表里。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
脚本里哪些操作会拖慢执行？
Lua 在 Redis 里是单线程同步执行的，任何耗时操作都会卡住整个 Redis 实例（不只是当前连接）。所以必须规避三类高危行为：
- 避免循环处理大量数据：比如
for i=1,10000 do redis.call("HGETALL", KEYS[1]) end—— 即使只读，1 万次调用也远超安全阈值 - 避免复杂计算：
tonumber(ARGV[1]) ^ 1000或正则匹配（Lua 标准库没 regex，但第三方库或自实现极易失控） - 禁止调用阻塞命令：
redis.call("BLPOP", ...)会直接报错，因为 Lua 环境不支持阻塞
真正安全的做法是：把计算逻辑尽量前置到客户端，Lua 脚本只做“键存在性判断 + 原子读写 + 简单算术”。例如限流脚本只做 INCR + EXPIRE + 比较，不自己实现滑动窗口算法。
脚本不是万能胶，它解决的是“多步操作的原子性 + 减少网络跳数”，而不是替代业务逻辑。最容易被忽略的一点是：一旦脚本出错（比如访问不存在的 key、除零、类型转换失败），整个脚本立即中断且无回滚——你得靠 redis.pcall 显式捕获，而不是指望它像事务一样自动 rollback。
