CLUSTER SLOTS 返回槽区间而非单槽归属，查具体槽需遍历其输出的[start,end]分段并二分匹配；最准确方式是用CLUSTER KEYSLOT算槽号后结合CLUSTER SLOTS查找，或直接解析MOVED响应。
CLUSTER SLOTS 返回的是槽范围，不是单个槽的归属
直接用 CLUSTER SLOTS 查某个具体槽（比如槽 12345）时，你得自己遍历返回的每一段区间——它不支持查单槽，只返回“[start, end] → node”的分段映射。常见错误是拿到结果后盯着第一行看，误以为所有槽都归那个节点管。
-
CLUSTER SLOTS输出里每行第一个数字是起始槽，第二个是结束槽，后面跟着负责该区间的节点 IP:端口 和角色标识（master 或 slave） - 槽 0–16383 是固定总数，但分段数量取决于集群规模和手动
CLUSTER ADDSLOTS的历史，可能只有几段，也可能几十段 - 如果节点下线或发生故障转移，
CLUSTER SLOTS仍会显示旧拓扑，需配合CLUSTER NODES核对节点状态（比如fail?或handshake状态）
CLUSTER NODES 里没有槽位信息，但能验证节点是否在线且主从关系正确
CLUSTER NODES 不告诉你哪个槽在哪，但它列出每个节点的 ID、IP:端口、角色（master/slave）、连接状态和负责的槽范围（以十六进制位图或区间形式）。很多人想靠它反查单槽，结果发现字段里只有 0-5460 这类区间，和 CLUSTER SLOTS 本质重复，只是格式更松散。
- 注意字段顺序：每行第 3 个字段是角色，第 9 个字段开始才是槽区间（如
0-5460或10000-10100），中间可能夹着connected或disconnected - 如果某节点标记为
slave却有槽区间，说明它被错误地配置成了主节点（比如通过CLUSTER SETSLOT手动迁移没清空原主节点的槽） - 位图格式（如
[1000-1005]）表示离散槽，比连续区间更难人工解析，建议优先用CLUSTER SLOTS查范围
查单个槽最稳的方式：用 CLUSTER KEYSLOT + CLUSTER SLOTS 组合定位
Redis 没有内置“查槽 X 归谁”的命令，但你可以用 CLUSTER KEYSLOT 先算出 key 对应的槽号，再拿这个数字去 CLUSTER SLOTS 的结果里二分查找所属区间——这是运维脚本和客户端 SDK 实际采用的逻辑。
-
CLUSTER KEYSLOT "user:1001"返回12345（整数） - 然后在
CLUSTER SLOTS输出中找包含 12345 的区间，比如12000 12999 192.168.1.10:7000 ...这一行 - 注意：不同 Redis 版本对
CLUSTER SLOTS的输出格式微调过（如 6.0+ 增加了 master ID 字段），解析脚本要兼容多版本 - 别用
KEYS或SCAN配合CLUSTER KEYSLOT批量查——这会阻塞节点且无法反映实时拓扑变化
容易被忽略的细节：MOVED 重定向响应里的槽信息最真实
当客户端发错节点时，Redis 返回的 MOVED 12345 192.168.1.10:7000 错误，其实已经告诉你槽 12345 当前归属——这个值来自运行时哈希表，比 CLUSTER SLOTS 更及时。很多监控脚本只扫静态拓扑，却漏掉正在迁移中的槽。
- 迁移中（
IMPORTING/MIGRATING状态）的槽，在CLUSTER SLOTS里仍显示旧归属，但MOVED响应已指向新节点 - 客户端必须处理
MOVED并更新本地缓存，否则持续打到错误节点，形成“伪热点” - 用
redis-cli -c模式执行命令时，它自动处理MOVED，但自研客户端常在这里翻车，尤其是未清理旧连接池
