不能。Redis Cluster强制要求Lua脚本中所有KEYS必须落在同一哈希槽，否则服务端入口校验即报CROSSSLOT错误；根本原因是集群按slot分片，脚本只能在单节点原子执行，无法跨节点协调。
Redis Cluster不支持跨Slot的Lua脚本执行
直接回答：不能。Redis Cluster强制要求一个Lua脚本中所有 KEYS 必须落在同一个哈希槽（slot）上，否则会报错 CROSSSLOT Keys in request don't hash to the same slot。这不是限制 Lua 功能，而是集群架构的底层约束——每个节点只负责部分 slot，脚本无法跨节点原子执行。
为什么 EVAL 会触发 CROSSSLOT 错误？
当你在集群中执行类似 EVAL "redis.call('get', KEYS[1]); redis.call('del', KEYS[2])" 2 key1 key2，而 key1 和 key2 经过 CRC16 计算后落入不同 slot（比如 1234 和 5678），Redis 就会在路由阶段直接拒绝，根本不会把脚本发给任何节点执行。
- 即使两个 key 逻辑上属于同一业务（如锁 key + 过期时间 key），只要没用
{}包裹，就大概率分属不同 slot -
redis.call()在集群模式下只能访问当前节点负责的 slot，不能代理转发 -
redis.pcall()也无法绕过这个限制，它只处理运行时错误，不解决路由校验失败
可行的绕过方案：用 Hash Tag 强制 key 落在同一 slot
核心是让所有参与锁逻辑的 key 共享同一个哈希标签，例如统一用 {order:1001} 作为前缀：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 加锁 key 改为
{order:1001}:lock - 持有者标识 key 改为
{order:1001}:owner - 过期时间 key 改为
{order:1001}:ttl
这样所有 key 的 CRC16 都只对 order:1001 计算，必然落到同一 slot，EVAL 就能通过路由检查。但注意：{} 内不能含空格、嵌套 {} 或未闭合，否则回退到全 key 散列。
真正需要跨 Slot 时，别硬扛 Lua 原子性
如果你的锁场景天然涉及多个业务实体（比如批量锁 10 个订单，各自 ID 散列到不同 slot），那 Lua 脚本这条路走不通。此时应放弃“单脚本全量原子”，转为：
- 逐个 key 执行带唯一 client_id + NX + PX 的
SET，失败则回滚已设的 key（需幂等） - 用 RedLock 算法（虽然有争议，但在多节点故障容忍上更现实）
- 改用客户端协调的租约机制，配合心跳续期和超时自动释放
最易被忽略的一点：很多人以为 “Lua = 分布式锁安全”，却忘了集群模式下它的作用域被 slot 切得支离破碎。真正的安全来自对 slot 边界的清醒认知，而不是强行把脚本塞进不匹配的架构里。
