加{}能解决CROSSSLOT错误，因Redis仅对首个成对{}内字符串做CRC16哈希，确保同tag的key落同一slot；但无法解决单key命令限制、集群禁用命令及性能卡顿等问题。
必须用哈希标签 {} 强制所有 KEYS 落在同一 slot，否则 EVAL 或 EVALSHA 必然报 CROSSSLOT 错误——这不是客户端能绕过的限制，是 Redis 集群的硬性设计。
为什么加 {} 就能解决 CROSSSLOT 报错
Redis 计算 slot 时，只取第一个成对 {} 包裹的内容做 CRC16 哈希，其余部分被忽略。比如 {user:1001}:profile 和 {user:1001}:settings 都只对 user:1001 哈希，必然落到同一 slot。
- 不合法写法：
user{1001}:profile（没闭合，整个 key 参与哈希，行为不可控） - 等效但易错写法：
user:{1001}:settings和{1001}:stats（都哈希1001，但语义模糊，建议统一风格） - 嵌套
{}只认最内层第一对：user:{abc{def}:xyz实际取def算 slot -
{}里不能为空：user:{}:profile会被当成整个 key 处理，失去控制力
KEYS 数组必须显式传入，且全部带相同 Hash Tag
脚本本身不决定 slot 分布，KEYS 数组传什么，Redis 才去查什么。即使脚本里写死 "user:1001:a"，只要没出现在 KEYS 里，就属于“非本地 key”，直接拒绝执行。
- ✅ 正确调用：
EVAL "return redis.call('GET', KEYS[1])" 2 {user:1001}:a {user:1001}:b - ❌ 错误调用：
EVAL "return redis.call('GET', 'user:1001:a')" 0（脚本内硬编码，无KEYS，集群模式下禁止） - 服务端生成 key 时就该带 tag，别等调用脚本时再拼接——Lua 里不能动态构造新 key 并保证它同 slot
- 客户端如 Lettuce/Jedis 会自动处理 ASKING 模式，但前提是传入的 key 已满足同 slot 条件；否则重定向后仍失败
哪些场景下 {} 也救不了你
{} 只管 key 分配，不管命令是否支持多 key。有些命令天生就是单 key 的，加了 {} 也没用。
-
INCR、LPOP、LPUSH等只接受一个 key 的命令，无法通过 Hash Tag “变”成多 key 操作 -
SCAN、KEYS在集群模式下被完全禁用，{}不可绕过 - 如果业务上必须读写多个无关用户的数据（比如后台批量统计），就别强撑 Lua 原子性——改用多次单 key 请求 + 客户端逻辑补偿
- 上线前必须用
redis-cli --cluster check看 slot 分布，确认打上相同 tag 的 key 真的落在了同一个 slot；光靠命名规则不验证，扩容或 rehash 后可能突然出问题
最容易被忽略的一点：Hash Tag 解决的是路由问题，不是聚合能力问题。就算所有 key 都落同一 slot，脚本里反复调用 redis.call()、在循环中用 SCAN，依然会卡死主线程、拖垮性能。真要聚合，优先用 SINTER、ZUNIONSTORE 这类原生命令。
