Redis集群执行Lua脚本失败大概率因KEYS未落在同一slot，必须用{}哈希标签确保所有KEYS经CRC16计算后归属相同slot，否则直接报CROSSSLOT错误，EVALSHA同理受限，脚本无法补救key设计缺陷。
Redis集群里执行Lua脚本失败，大概率是因为KEYS没落在同一个slot——这不是脚本写得不对，是key设计没对齐。
为什么EVAL或EVALSHA报CROSSSLOT错误
Redis集群把16384个slot分到不同节点，每个key按规则算出归属slot。Lua脚本要求所有KEYS必须在同一slot，否则直接拒绝执行，连解析脚本都不做。
- 错误信息典型长这样：
(error) CROSSSLOT Keys in request don't hash to the same slot或ERR 'EVAL' command keys must in same slot - 单机Redis完全不检查这个，所以本地测通、上集群就崩，非常容易漏掉
-
EVALSHA不是“绕过”方案：它只是发sha1值，但校验逻辑和EVAL完全一致，仍强制同slot - Jedis、Lettuce等客户端在调用
eval前会先调JedisClusterCRC16.getSlot()逐个检查KEYS，不一致就抛JedisClusterException
用{}做HashTag是最直接的解法
Redis允许你用{}标记key中参与哈希计算的部分，只取第一个{}对里的字符串做CRC16，其余部分忽略。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 正确示例：
user:{1001}:profile、cart:{1001}:pending、order:{1001}:items→ 都用1001算slot，必然同节点 - 错误示例：
user:1001:profile、order:1001:items→ 整个字符串参与哈希，user:1001:profile和order:1001:items基本不可能同slot - 嵌套
{}只认最内层第一对：user:{abc{def}:xyz实际取def算slot - 大括号里不能为空：
user:{}:profile会被当成整个key处理，失去控制力
脚本里怎么组织KEYS和ARGV
Lua脚本本身不解决slot问题，它只是执行容器；真正起作用的是你传进去的KEYS数组——它们必须已满足同slot条件。
- 不要在脚本里拼接key：
KEYS[1] .. ":counter"生成的新key不会被校验，运行时可能NOAUTH或MOVED - 所有要操作的key，必须显式传进
KEYS参数，不能靠脚本内部构造 - 示例安全写法：
-- 正确：所有key由客户端传入，且已保证同slot
local userKey = KEYS[1]
local counterKey = KEYS[2]
redis.call('SET', userKey, ARGV[1])
return redis.call('INCRBY', counterKey, ARGV[2])- 如果业务ID藏在value里（比如用UUID作key），就得提前从value里抽出来，再拼成带
{}的key写入——脚本不能补救设计缺陷
调试时怎么快速验证slot是否一致
别靠猜，用工具直接看结果。
- 命令行查slot：
redis-cli -c -h your-cluster-host -p 6379 cluster keyslot user:{1001}:profile - Java里用
JedisClusterCRC16.getSlot("user:{1001}:profile")打印对比 - 注意：
cluster nodes输出的slot范围（如0-5460）只是分配区间，具体key落哪槽得单独算 - 线上环境别用
redis-cli -c直接跑EVAL测试——它会自动重定向，掩盖真实错误路径；应连接具体节点IP+端口直连复现
最容易被忽略的一点：HashTag不是“可选优化”，而是集群下多key Lua 脚本的**前提条件**。哪怕你只读两个key，只要它们不在同一slot，脚本就根本不会开始执行。
