SCRIPT KILL 仅能中断等待阻塞命令返回的脚本，对纯计算循环或密集非阻塞调用无效；需确认连接主节点、检查 SCRIPT LIST 或 CLIENT LIST 状态，真正可控的是客户端超时断连与服务端 lua-time-limit 配合代码审查。
SCRIPT KILL 为什么经常没反应
脚本卡住后执行 SCRIPT KILL 返回 (error) ERR No scripts in execution right now，不是命令输错了，而是它根本没作用到目标脚本上。Redis 的 SCRIPT KILL 只对当前连接所连节点生效，且仅能中断“正在等待阻塞命令返回”的脚本（比如刚调用完 BLPOP 还没拿到数据），一旦脚本进入纯计算循环、或密集调用 redis.call("GET") 等非阻塞命令，就不再检查中断信号——此时 SCRIPT KILL 彻底失效。
确认脚本是否真在运行且可被终止
先用 INFO replication 或 ROLE 确认你连的是主节点；再执行 SCRIPT LIST（Redis 7.0+）或 CLIENT LIST 查看是否有 cmd=eval 且 state=running 的连接。如果 CLIENT LIST 里显示某连接的 cmd 是 eval 但 state 是 idle 或 wait，说明脚本早已退出或卡在不可中断阶段，SCRIPT KILL 不会起效。
-
SCRIPT KILL成功时返回OK，失败时返回明确错误，不会静默失败 - 集群环境下，必须确保
redis-cli -c连接的是该 key 所在 slot 的主节点，否则命令发错地方 -
SCRIPT EXISTS能查脚本是否还缓存着，但不能反映当前执行状态
真正可控的终止手段：客户端主动断连 + 服务端限流兜底
别指望靠运行时 kill 解决问题，重点是让脚本压根跑不起来或跑不久：
- 客户端连接必须设
socketTimeout（Jedis）或CommandTimeout（Lettuce），超时后自动断开连接，避免连接长期 hang 住 - 服务端配置
lua-time-limit 5000，但它只对阻塞型等待有效；对for i=1,100000 do ... end这类纯计算无效，必须靠代码审查禁用 - 禁止在 Lua 中做 JSON 解析、正则匹配长文本、递归调用等操作——这些都应前置到应用层
- 对必须分批处理的场景，改用
SCAN+ 客户端控制节奏，而不是把全量逻辑塞进一个 Lua 脚本里
清理残留状态的最后手段：SCRIPT FLUSH + 主从同步重置
如果脚本已触发超时并被 Redis 标记为 “killed”，但实际仍在 CPU 上跑（top -p 能看到高 CPU），且无法通过正常方式终止，只能清缓存并接受短暂影响：
- 执行
SCRIPT FLUSH清除所有已加载脚本的 SHA1 缓存，后续EVALSHA全部降级为EVAL - 注意：这不会终止正在运行的脚本，只是让新请求不再复用旧缓存
- 若主从结构中从节点也卡住，需手动在从节点执行
SCRIPT FLUSH，否则主从脚本缓存不一致可能导致后续EVALSHA报NOSCRIPT - 极端情况下，可对从节点执行
DEBUG RELOAD（仅限开发/测试环境），但生产环境应优先考虑重启从节点
真正难处理的从来不是“怎么杀”，而是“为什么它能跑这么久”——脚本里有没有隐式死循环？有没有忽略 redis.call() 的返回值导致反复重试？这些细节比 SCRIPT KILL 的成败更值得花时间盯。
