Redis 6.0集群中EVAL/EVALSHA严禁跨槽执行，报CROSSSLOT错误是硬性设计限制；唯一解法是用{}哈希标签使所有KEYS参与哈希的部分相同，确保落同一slot。
Redis 6.0 集群中根本不存在“高效调度跨槽 Lua 脚本任务”这回事——EVAL 和 EVALSHA 在集群模式下严格禁止跨槽执行，报 CROSSSLOT 错误不是性能问题，是设计硬限制。所谓“调度”，本质是规避错误，而非优化执行。
为什么 EVAL 在 Redis 6.0 集群里必然报 CROSSSLOT
集群把 16384 个 slot 分散到多个节点，每个 key 按 CRC16(key) % 16384 算出归属 slot；Lua 脚本执行前，Redis 会检查所有 KEYS 参数是否落在同一 slot，只要有一个不同，立刻拒绝，连脚本解析都不做。错误信息典型为：(error) CROSSSLOT Keys in request don't hash to the same slot。
这不是客户端能绕过的逻辑，Jedis、Lettuce 等主流客户端在调用前就会调用 JedisClusterCRC16.getSlot() 或等效方法校验，不一致直接抛 JedisClusterException。
常见踩坑点：
- 本地单机 Redis 测通了，一上集群就崩——单机不校验 slot，掩盖了 key 设计缺陷
- 以为
EVALSHA是“绕过方案”——它只发 sha1，校验逻辑和EVAL完全一致，照样报错 - 在脚本里拼接新 key，比如
KEYS[1] .. ":counter"——这个 key 不在KEYS数组里，属于“非本地 key”，运行时报ERR Lua script attempted to access a non-local key
必须用 {} 哈希标签对齐所有 KEY 的 slot
这是唯一被官方支持、无需改集群配置、不依赖客户端分片逻辑的解法：Redis 计算 slot 时，只取第一个成对 {} 内的内容参与 CRC16，其余部分忽略。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
正确写法示例（都强制落到同一 slot）：
user:{1001}:profilecart:{1001}:pendingorder:{1001}:items
关键约束：
- 所有要传入
KEYS的 key，必须显式带相同哈希标签，不能靠脚本内构造 - 嵌套
{}只认最内层第一对，user:{abc{def}:xyz实际取def哈希 -
{}不能为空，user:{}:profile会被当成整个字符串哈希，失去控制力 - 服务端写入 key 时就必须带 tag，别等调用脚本才想怎么拼
上线前必须验证 slot 是否真对齐
光靠命名规则不验证，扩容或 CLUSTER SETSLOT 后可能突然失败。必须实测：
- 用
redis-cli -c连集群，执行CLUSTER KEYSLOT user:{1001}:profile和CLUSTER KEYSLOT cart:{1001}:pending，确认返回值一致 - 用
redis-cli --cluster check <host>:<port>查看 slot 分布，确认这些 key 对应的 slot 确实由同一节点负责 - 若业务 key 本身不含稳定 ID（如用 UUID），必须在应用层提取/约定一个稳定字段塞进
{}，例如从order:abc-def-ghij中提取abc作为 tag
最容易被忽略的是：Hash Tag 只解决 key 分布，不解决命令兼容性。像 SCAN、KEYS、MGET（无 tag 时）在集群里仍受限或禁用，别指望靠 tag “激活”它们。
