redis 7.0起彻底移除script debug命令，6.x默认禁用，启用会导致性能崩溃；防lua宕机需依赖lua-time-limit熔断、keyspace事件监控和evalsha预加载三大机制。
SCRIPT DEBUG 命令根本不能用于生产环境调试
Redis 从 7.0 开始彻底移除了 SCRIPT DEBUG 命令，6.x 版本虽保留但默认禁用，且启用后会强制开启慢日志、禁用 AOF 重写、阻塞所有 Lua 执行——这不是调试手段，是自毁开关。你看到的文档或旧教程里提到的 SCRIPT DEBUG yes，在真实生产 Redis 实例上执行只会返回 (error) ERR Unsupported CONFIG parameter: debug 或直接拒绝。
- Redis 6.2+ 默认编译时就禁用调试支持，除非手动加
--enable-debug重新编译（不推荐） - 即使强行启用，
SCRIPT DEBUG只支持单步进入redis.call()，无法设断点、看变量、跳过循环，实际调试效率极低 - 它会让整个 Redis 实例退化为单线程串行执行，QPS 跌穿 100，连接超时雪崩随之而来
真正能防 Lua 宕机的三个硬控制点
防宕机不是靠事后调试，而是靠上线前卡死边界。Redis 提供了三道可配置的熔断机制，必须显式打开并调优：
-
lua-time-limit：单位毫秒，默认 5000。超过即触发BUSY Redis is busy running a script错误，但注意——它只中断脚本执行，不杀进程，也不释放锁；若脚本持有SET key val NX PX 10000后卡住，这个锁就永远挂着 -
notify-keyspace-events配合E事件：监听__keyevent@0__:del等信号，在外部服务中自动清理残留锁或标记异常脚本 ID - 使用
EVALSHA替代EVAL，配合SCRIPT LOAD预加载 +SCRIPT EXISTS校验，避免每次传输大脚本导致网络延迟放大执行时间
本地模拟与快速验证 Lua 脚本是否危险
别等上生产再试。用 redis-cli 连测试实例，套一层超时包装器，观察真实行为：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
timeout 3 redis-cli --eval 'local i=0; while true do i=i+1 end' 2>/dev/null || echo "killed by timeout"
更关键的是检查脚本是否隐含 O(n) 操作：
- 用
KEYS *—— 绝对禁止，改用SCAN+ 游标分批 - 对大集合用
SMEMBERS或对大有序集用ZRANGE key 0 -1—— 改成SSCAN/ZSCAN分页 - 嵌套循环遍历 KEYS 数组再逐个
redis.call("GET", k)—— 合并为redis.call("MGET", unpack(KEYS))
出了问题怎么快速止血而不是查原因
当监控发现 used_cpu_sys_children 突增、 instantaneous_ops_per_sec 归零、客户端大量 BUSY 报错时，立刻执行：
- 运行
SCRIPT KILL—— 仅对「未修改数据」的脚本有效（比如纯计算、只读GET），它会立即终止当前执行 - 若已执行过
SET/DEL等写命令，SCRIPT KILL失效，必须SHUTDOWN NOSAVE强制重启（依赖 RDB 快照恢复） - 重启后第一件事：用
redis-cli --scan --pattern "lock:*" | xargs -n 100 redis-cli DEL清理可能残留的业务锁
真正麻烦的从来不是脚本写得有多炫，而是它在第 37 次循环时访问了一个不存在的 key，触发了隐式字符串分配，最终耗尽内存——这种细节，SCRIPT DEBUG 帮不上忙，只有压测 + 资源监控 + 写法约束能兜住。
