不能靠“禁用”Lua，只能靠ACL精准拦截EVAL和EVALSHA命令——这是Redis 6.0+最可靠、最细粒度的防护方式；lua-time-limit 0并非禁用开关，仅设超时阈值，无法阻止脚本执行，且对短时高危脚本完全无效。
直接结论：不能靠“禁用”Lua，只能靠ACL精准拦截 EVAL 和 EVALSHA 命令——这是当前 Redis 6.0+ 最可靠、最细粒度的防护方式。
为什么不能用 lua-time-limit 0 禁用 Lua？
这个配置项只是限制脚本最大运行时间（毫秒），设为 0 并不会阻止脚本执行，反而可能让恶意脚本无限循环卡死线程。它不是开关，是超时阈值。官方文档明确说明：该参数不提供禁用能力。真实场景中，攻击者仍可提交极短但高危的 Lua 脚本（如篡改 GC 行为触发 CVE-2024-46981），lua-time-limit 完全无效。
ACL SETUSER 中如何精确屏蔽 Lua 相关命令？
必须显式拒绝 EVAL 和 EVALSHA，且注意权限叠加逻辑：
-
ACL SETUSER myapp -@all +@read +@write -EVAL -EVALSHA：先清空所有权限（-@all），再加读写类权限，最后单独剔除两个 Lua 命令 - 不能只写
-EVAL而漏掉-EVALSHA——后者是前者缓存哈希调用形式，绕过检测极容易 - 避免混用
+@scripting：这个类别包含全部脚本命令（EVAL、EVALSHA、SCRIPT LOAD、SCRIPT EXISTS等），开了就等于放行全部 Lua 功能 - 若用户需用
SCRIPT LOAD预加载（如某些 ORM 框架），则必须单独放行该命令，但依然要严格禁止EVAL和EVALSHA
验证是否生效的三个关键检查点
ACL 规则写完不等于安全落地，必须手动验证：
- 用目标用户登录：
redis-cli -u redis://myapp:password@127.0.0.1:6379，再执行ACL WHOAMI确认身份 - 尝试执行
EVAL "return 1" 0，应返回(error) NOPERM this user has no permissions to run the 'eval' command - 检查
ACL LIST输出中对应用户的规则行，确认含-EVAL和-EVALSHA字样，且无+@scripting或+EVAL类正向授权
真正容易被忽略的是：ACL 规则对已存在的连接不生效，必须重启客户端或执行 AUTH 重新鉴权；另外，Redis 6.0 的 ACL 不支持通配符匹配命令名（比如不能写 -EVAL*），每个需禁用的命令都得列全。
