Redis Lua脚本执行失败常因忽略redis.call()返回值，应检查是否为错误表；EVALSHA需确保脚本已重载；redis.log()日志需调高loglevel且查服务端文件；KEYS必须显式声明，禁用KEYS命令。
Redis Lua脚本执行失败但没报错？检查redis.call()返回值是否被忽略
Redis Lua里redis.call()出错不会抛异常，而是直接返回nil或错误对象（如error "ERR no such key"），但很多人写成local res = redis.call("GET", "x")后直接用res做判断，结果res是nil还继续往下走，逻辑就歪了。
实操建议：
- 每次
redis.call()后立刻检查返回值：if type(res) == "table" and res.err then error(res.err) end - 用
redis.pcall()替代redis.call()更安全，它总是返回{ok, result}或{err, message}结构 - 别在Lua里拼接字符串做key名再
call——如果拼错了，Redis根本不会提示“key不存在”，只会静默返回nil
本地调试Lua脚本时，EVAL和EVALSHA行为不一致？注意缓存与重载问题
EVALSHA依赖脚本SHA1缓存，但本地改完脚本再发EVALSHA，Redis仍执行旧版本——因为SHA1没变（内容没重发），而你又没清缓存。
实操建议：
- 开发阶段一律用
EVAL，禁用EVALSHA；上线前才切 - 用
SCRIPT FLUSH清空所有已缓存脚本（测试环境可放心用） - 用
SCRIPT LOAD预加载并拿到SHA1，再用EVALSHA测试——确保你加载的是最新版 - 注意：不同Redis实例间脚本缓存不共享，集群中每个节点要单独
SCRIPT LOAD
脚本里用redis.log()打日志，为什么看不到输出？
redis.log()不是打印到控制台，而是写进Redis服务端日志文件（路径由logfile配置项决定），且默认只记录WARNING及以上级别。你写了redis.log(redis.LOG_NOTICE, "debug: "..val)，大概率被过滤掉了。
实操建议：
- 临时把Redis配置改成
loglevel verbose或debug（仅限开发机） - 确认
logfile路径可写，且你有权限读它（比如/var/log/redis/redis-server.log） - 别依赖
redis.log()做关键逻辑分支——它只是辅助手段，不能替代返回值校验 - 线上禁止用
LOG_DEBUG，大量日志会拖慢脚本执行，甚至触发Redis慢日志误报
多个key操作被KEYS参数限制死？绕过EVAL的key约束其实很危险
Redis强制要求所有操作key必须显式传入KEYS数组，否则EVAL直接报错ERR script tried to access a non-existent key。有人用redis.call("KEYS", "user:*")绕过，这是错的——KEYS命令本身被禁用（除非关掉lua-time-limit且允许阻塞），而且破坏了Redis Cluster的key分布规则。
实操建议：
- Cluster模式下，所有
KEYS参数里的key必须落在同一个slot，否则EVAL直接拒绝执行 - 真需要扫描，拆成客户端多次调用，或改用
SCAN配合游标（但SCAN不能用于事务内） - 用
{key1, key2}明确列出所有key，哪怕多传几个空占位符，也比动态发现安全 - 注意：
ARGV里放key名是无效的——Redis只认KEYS[1]这种形式
最麻烦的从来不是写对Lua语法，而是搞清Redis怎么看待这段代码：它不信任你，不给你stdout，不让你碰未知key，连报错都可能藏在返回值里。调的时候少想“我写了什么”，多问“Redis收到了什么、又返回了什么”。
