必须用redis.newclusterclient()初始化集群连接，因newclient()不解析cluster slots、不处理moved/ask重定向、不执行crc16 slot映射，导致命令打错节点后直接报错；需配置addrs（至少一个主节点）、readonly、routebylatency/routerandomly及maxredirects等参数。
必须用 redis.NewClusterClient() 初始化集群连接，redis.NewClient() 连 Redis 集群会反复报 MOVED 或直接连接拒绝——这不是配置问题，是客户端类型错配。
为什么 NewClient() 在集群里必然失败
单节点客户端不解析 CLUSTER SLOTS，不处理 MOVED/ASK 重定向，也不做 key → slot 的 CRC16 映射。你发一个 GET user:1001，它可能打到任意节点；若该节点不负责这个 key 的 slot，就原样返回 MOVED 12345 10.0.1.5:6379，而 NewClient() 不重试、不跳转，直接把错误透传给你。
- 常见现象：
redis: MOVED 12345 10.0.1.5:6379循环出现，或connection refused（因连了已下线节点且不刷新拓扑） - 哪怕只填一个地址如
"127.0.0.1:7000"，NewClusterClient()也会自动拉取全部节点和 slot 分布 - 集群节点间端口必须互通（不只是客户端能连），否则
CLUSTER SLOTS请求失败，启动时直接报redis: cluster supports only redis v3.0+这类误导性错误
ClusterOptions 关键参数怎么设才不踩坑
初始化 redis.NewClusterClient() 时，ClusterOptions 表面简单，但几个字段设错就会导致路由异常、读写分离失效或连接卡死。
-
Addrs必须是[]string{"host:port"}格式，不能带redis://；至少填一个在线节点，多个更容灾 -
ReadOnly默认false；设为true后读请求可能落到 slave，但需确认 Redis 配置了slave-read-only no或用了 Redis 6+ 的READONLY命令支持 -
RouteByLatency和RouteRandomly控制读请求分发策略；不设则所有读都打 master，容易压垮主节点 -
MaxRedirects默认 8，建议保留；若实际重定向次数频繁超限，说明集群拓扑异常（如大量 fail 节点或 slot 分配不均）
多 key 操作和事务在集群里怎么写才安全
集群模式下，MGET、DEL、Pipeline 等操作不是“不能用”，而是必须满足 slot 一致性——所有 key 必须落在同一个 slot，否则直接返回 CROSSSLOT Keys in request don't hash to the same slot。
- key 带大括号分组（如
"user:{1001}:profile"）才能确保同业务数据 hash 到同一 slot - 不要手动算 CRC16：客户端内部已封装，你只需保证 key 格式合规
- 真要批量操作不同 slot 的 key，得先按
{key} → slot分组，再并发提交；别指望一条命令扫全量 - 事务（
PIPELINE）里混用跨 slot key 一样失败，且错误发生在Exec()阶段，不是Set()时
Do 方法的返回类型为什么总变？
Do() 在集群模式下不是简单透传，而是根据命令类型 + key 分布动态决定执行路径，所以返回值类型不固定。
- 单 key 命令（
GET、SET）→ 自动路由到对应节点，返回该节点原始响应类型（如*redis.StringCmd） - 无 key 命令（
INFO、TIME）→ 默认发给第一个可用节点，返回其响应 - 广播命令（
CLIENT LIST、CONFIG GET）→ 并行发给所有节点，聚合结果为[]interface{}，Val()返回切片，得用StringSlice()或手动断言 - 别硬写
cmd.Val().(string)；统一先调cmd.Result()检查 error，再按文档判断是否可直接Val()
最易被忽略的是：集群客户端首次发现拓扑可能耗时 >1s，别把 DialTimeout 设成 100ms；还有，生产环境务必关掉默认的 ReadOnly=false 和 RouteByLatency=false，否则读流量全压 master，扩容就失去意义。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
