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，看似随机，但实际结果可预测。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 别指望
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 —— 所以“绕过检查”的尝试注定失败。
