go-redis连接Redis Cluster报MOVED/ASK错误，是因为误用redis.NewClient()而非redis.NewClusterClient()；正确做法是用NewClusterClient()并配置至少一个集群节点地址，且节点间端口互通。
go-redis 连接 Redis Cluster 时为什么总报 MOVED 或 ASK 错误？
不是你的代码写错了，是没走对集群客户端初始化路径。go-redis 的 redis.ClusterClient 和单节点 redis.Client 完全不同，它必须显式传入多个起始节点地址（哪怕只写一个），且依赖这些节点返回的集群拓扑自动发现其他节点。
- 错误做法：用
redis.NewClient()去连集群地址 → 会当单机用，遇到重定向就 panic 报MOVED - 正确入口是
redis.NewClusterClient()，且.Addrs至少填一个可用的集群节点（如"127.0.0.1:7000"） - 集群节点间端口必须互通（不只是客户端能连某一个），否则
CLUSTER SLOTS拉取失败，ClusterClient启动直接报redis: cluster supports only redis v3.0+这类误导性错误 - 别在
.SetPingTimeout或.SetDialTimeout上设太小，拓扑首次发现可能耗时 >1s
如何让 go-redis 正确路由到目标 slot 而不手动算 key hash？
根本不用你算。go-redis 的 ClusterClient 内部已封装了 CRC16 + slot 映射逻辑，所有命令（Get、Set、HGetAll 等）都会自动提取 key 并路由到对应节点。但有两个关键前提：
- key 必须带大括号分组（如
"user:{1001}:profile"），否则 hash 基于整个字符串，可能导致同业务数据分散在不同 slot - 多 key 操作（如
MGET、DEL）要求所有 key 落在同一 slot，否则直接返回redis: CROSSSLOT Keys in request don't hash to the same slot - 事务（
Pipeline）里混用不同 slot 的 key 也会失败；若真要批量操作，得按 slot 分组后并发提交
为什么 ClusterClient 的 Do 方法有时返回 *redis.StringCmd，有时是 *redis.SliceCmd？
因为集群模式下，Do 不再是简单透传，而是根据命令类型和 key 分布动态决定执行方式。底层做了三类处理：
- 单 key 命令（
GET、SET）→ 自动路由到对应节点，返回该节点原始响应类型 - 无 key 命令（
INFO、TIME）→ 默认发给第一个可用节点，返回其响应 - 广播命令（
CLIENT LIST、CONFIG GET）→ 并行发给所有已知节点，聚合结果为[]interface{}，所以Val()返回[]interface{}，需用StringSlice()或手动类型断言
别假设返回类型固定——用 cmd.Val() 前先看文档确认命令是否跨节点，或统一用 cmd.Result() 捕获 error 再处理值。
立即学习“go语言免费学习笔记（深入）”；
生产环境必须关掉的两个默认配置
ClusterClient 开箱即用的配置在压测或长连接场景下容易出问题：
-
.MaxRedirects = 8（默认值）→ 集群拓扑变更频繁时可能陷入重定向循环，建议设为2，配合监控告警而非盲目重试 -
.RouteByLatency = false（默认），但开启后需要定期CLIENT REPLY OFF探活，实际增加延迟；除非你有明确低延迟诉求且能接受额外心跳开销，否则保持关闭 - 另外，
.ReadOnly模式默认关着，如果只读流量大，可开redis.ClusterOptions.ReadOnly = true让从节点分担压力，但要注意从节点可能有秒级延迟
集群拓扑刷新不是实时的，节点上下线后，客户端最快也要等一次 RefreshInterval（默认 5 分钟）才会感知，这期间请求可能持续失败。别只盯着连接池参数调优，先确保运维侧做了正确的 CLUSTER FAILOVER 和 CLUSTER RESET 流程。
