根本原因是客户端未获取集群拓扑，常见于初始节点列表含从节点或集群总线端口（如7379）不通；newclusterclient() 必须显式设置 routebylatency/routerandomly、maxredirects 和 readonly，且 addr 列表应全为主节点。
go-redis 连接 Redis Cluster 时为什么报 cluster slots failed？
根本原因是客户端没拿到集群拓扑，而常见诱因是初始节点列表里混入了从节点（replica），或节点间网络不通但没暴露真实错误。go-redis 的 NewClusterClient() 默认只向列表中第一个可连上的节点发 CLUSTER SLOTS，如果那个节点恰好是只读从节点（不响应该命令），就会直接失败。
- 确保传给
redis.NewClusterClient()的Addr列表全是主节点（master）地址，哪怕只有一个也行——它会自动发现其余节点 - 检查每个节点是否能手动执行
redis-cli -h x.x.x.x -p yyyy cluster slots，返回非空数组才算有效 - 防火墙或 Kubernetes Service 配置可能屏蔽了集群总线端口（通常是 client port + 1000），比如 client 用 6379，总线就得通 7379；这个端口不通时，
cluster slots会超时或静默失败
用 NewClusterClient() 初始化时哪些配置不能省？
和单机 NewClient() 不同，集群模式下几个字段不设会导致连接成功但后续操作随机失败——尤其是路由错乱或重试爆炸。
-
RouteByLatency: true或RouteRandomly: true必须显式设一个，否则默认行为未定义，某些版本会 fallback 到固定节点导致负载倾斜 -
MaxRedirects: 8建议设为 8（默认是 -1），避免集群拓扑剧烈变更时陷入无限重定向循环 -
ReadOnly: false如果业务需要写，千万别漏掉；设成true后所有写命令（如SET）会直接返回MOVED错误而非自动重试
为什么 GET 成功但 PIPELINE 报 CROSSSLOT？
Redis Cluster 对 pipeline 有硬性限制：同一个 pipeline 里的所有 key 必须落在同一个 slot（即同一主节点）。go-redis 默认把 pipeline 当作“一批独立命令”发出去，不会做 slot 聚合，所以一旦 keys 分散，服务端就拒绝执行。
- 别在 pipeline 里混用不同业务前缀的 key，例如
user:123和order:456很可能不在同个 slot - 真要批量操作多 key，优先用
MGET/MSET这类原生命令，它们内部已做 slot 校验 - 若必须 pipeline，先用
redis.ClusterSlot(key)算出 slot ID，按 slot 分组构造多个 pipeline，再并发执行
故障转移后客户端卡住几秒才恢复？
不是网络延迟，是 go-redis 默认的拓扑刷新机制太保守：它只在收到 MOVED 或 ASK 响应时才更新节点映射，而故障转移初期新主节点可能还没被旧客户端“感知”到，导致请求持续打到已下线节点上，直到超时。
- 加
RefreshInterval: 5 * time.Second，让客户端主动轮询CLUSTER SLOTS更新拓扑 - 同时设
ReadOnly: true（仅读场景）或ReadOnly: false（读写混合），配合RouteByLatency，能更快切到新主节点 - 注意
RefreshInterval太小（如 500ms）会增加集群总线压力，一般 3–10 秒足够平衡灵敏度与开销
集群模式下最麻烦的从来不是连不上，而是连上了却走错节点、分片键算错、拓扑缓存过期不及时——这些都不会立刻报错，而是以慢查询、数据不一致或偶发失败的形式出现，得盯着 redis-cli --cluster check 输出和客户端日志里的 MOVED 行数才能揪出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
