为什么Redis Lua脚本中无法使用动态生成的Key_遵循KEYS数组传递参数规范

Redis集群要求Lua脚本中key必须直接使用KEYS[1]等字面量形式，因slot校验在执行前静态分析，不识别变量或ARGV；否则报错ERR bad lua script。

为什么 Redis 集群里 Lua 脚本必须用 KEYS[1] 而不能赋值给变量再用

因为 Redis 集群在执行脚本前，要静态分析所有被操作的 key 所属 slot，确保它们落在同一个分片上。这个分析只认字面量形式的 KEYS[n]（比如 KEYS[1]、KEYS[2]），不识别任何中间变量或表达式。

一旦你写 local k = KEYS[1]; redis.call("GET", k)，Redis 就无法在解析阶段确认 k 指向哪个 key，也就无法校验 slot 一致性——直接拒绝执行，报错 ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS array。

• 阿里云 Redis、腾讯云 CRS、AWS ElastiCache 等主流集群版均强制此规则
• 单机版 Redis 不校验 slot，所以同样脚本可能“本地跑得通，上集群就挂”
• 不是性能优化，是路由前提：没这一步，Redis 根本不知道该把脚本发给哪个节点

KEYS 数组里放错一个 key 就会报 ERR eval/evalsha command keys must in same slot

集群要求所有 KEYS 中的 key 必须属于同一个 slot，否则脚本连解析都过不去。Redis 用 CRC16(key) % 16384 算 slot，看似随机，但实际结果可预测。

• 别指望 user:1001 和 user:1002 一定同 slot —— 它们 hash 后很可能落在不同分片
• 如果真要批量操作多个 key，必须用 {tag} 方式强制对齐 slot，例如 user:{1001}:profile 和 user:{1001}:settings（花括号内相同）
• 用 redis-cli --cluster check 或 CLUSTER KEYSLOT <key> 可验证 slot 分布

为什么 ARGV 不能当 key 用，哪怕它传的是字符串

ARGV 是纯数据容器，Redis 明确禁止在 redis.call() 的 key 参数位置使用 ARGV[n]。哪怕 ARGV[1] 的值是 "mykey"，写成 redis.call("GET", ARGV[1]) 也会触发 ERR bad lua script。

• 根本原因：ARGV 值在脚本运行时才确定，Redis 无法在预检阶段提取其内容做 slot 校验
• 常见翻车点：用户想“复用脚本”，把 key 名也当参数传，结果把本该进 KEYS 的值塞进了 ARGV
• 正确做法：key 名必须出现在 EVAL 命令的 key 列表中（决定 KEYS 内容），且脚本里只能以 KEYS[1] 形式硬引用

EVAL 命令参数顺序错一位，整个 KEYS/ARGV 映射就全乱

EVAL 命令结构是：EVAL <script> <numkeys> <key1> <key2> ... <arg1> <arg2> ...。其中 numkeys 是整数，决定了前几个参数进 KEYS，剩下的全进 ARGV。

• 写成 EVAL "return KEYS[1]" 1 mykey hello → KEYS[1] == "mykey"，ARGV[1] == "hello"
• 但若误写 EVAL "return KEYS[1]" 0 mykey hello → KEYS 为空，ARGV[1] == "mykey"，ARGV[2] == "hello"，脚本访问 KEYS[1] 就报 attempt to index a nil value
• Python/Java 客户端 SDK 一般封装了 key/argv 自动拆分，但 raw 命令或调试时务必手数参数个数

最易被忽略的一点：slot 校验发生在脚本加载前，和 Lua 逻辑是否执行无关。哪怕你脚本里 if false then redis.call("GET", KEYS[1]) end，只要语法上出现了 KEYS[1]，Redis 就会去查它所属 slot —— 所以“绕过检查”的尝试注定失败。