必须使用 redis.newclusterclient() 连接 redis 集群，因 redis.newclient() 不支持槽位路由、节点发现与重定向，直接连接必报 moved/ask 错误；newclusterclient() 自动拉取 cluster slots、处理重试与故障转移，并需正确配置 addrs（至少两个主节点）、readonly、routebylatency 及 maxredirects 等关键参数。
必须用 redis.NewClusterClient()，redis.NewClient() 连集群必报 MOVED
直接用 redis.NewClient() 去连 Redis 集群地址，哪怕只填一个节点，也一定会失败。这不是密码错、网络不通或配置漏，是根本性类型错配：单节点客户端不解析 CLUSTER SLOTS，不计算 key → slot 的 CRC16 映射，也不处理 MOVED 或 ASK 响应。你发一个 GET user:1001，它可能随机打到任意节点；若该节点不负责这个 slot，就原样返回 redis: MOVED 12345 10.0.1.5:6379，而 NewClient() 不重试、不跳转，直接把错误透传给你。
常见现象包括：redis: MOVED ... 循环出现、connection refused（因连了已下线节点且不刷新拓扑）、或命令静默失败。只要你的 Redis 是用 redis-cli --cluster create 搭的 3 主 3 从结构，就必须用 NewClusterClient()。
Addrs 怎么填、ReadOnly 和 RouteByLatency 为什么不能默认不管
Addrs 是启动时发现集群拓扑的起点，必须是 []string{"host:port"} 格式，不能带 redis://，也不能写数据库编号（集群不支持 SELECT）。填一个在线节点就能拉取全部拓扑，但建议至少填两个，防止单点不可达导致初始化失败。
ReadOnly 默认为 false，即所有读请求都打主节点——这在高并发读场景下极易压垮 master。设为 true 后，读请求才可能落到 slave，但需确认 Redis 配置了 slave-read-only no，或你用的是 Redis 6+ 并启用了 READONLY 命令支持。
RouteByLatency 和 RouteRandomly 控制读请求分发策略。不设这两个字段，读请求就全走 master；设 RouteByLatency: true 会让客户端定期探测各节点延迟并优先选快的；设 RouteRandomly: true 则随机选可用 slave。两者别同时设，否则行为未定义。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
Addrs: []string{"10.0.1.1:6379", "10.0.1.2:6379"}ReadOnly: trueRouteByLatency: true-
MaxRedirects: 8（保持默认即可，超限说明集群拓扑异常）
Key 必须带 {tag}，否则 MGET、DEL 会报 CROSSSLOT
Redis 集群按 slot 分片，每个 key 经 CRC16(key) mod 16384 计算归属槽位。如果多个 key 落在不同 slot，像 MGET user:1001 user:1002 这种批量操作就会被拒绝，返回 CROSSSLOT Keys in request don't hash to the same slot。
解决办法是显式控制哈希行为：用大括号包裹共属 tag，例如 user:{1001}:profile 和 user:{1001}:settings 会强制落在同一 slot，支持批量读写。避免纯数字递增 key（如 order_1、order_2），容易导致数据倾斜；可加随机后缀，如 order_1#f8a2。
事务（WATCH/MULTI/EXEC）和 pipeline 同样受此限制。涉及关联数据的多 key 操作，若无法共用 tag，就得接受应用层 join，或改用单节点 Redis + 分库逻辑。
连接失败先查集群状态，别急着改 Go 代码
Go 客户端连不上集群，大概率不是代码问题，而是底层集群本身不健康。调试顺序应该是：
- 用
redis-cli -c -h 10.0.1.1 -p 6379 ping测试是否能进集群模式（注意-c参数），返回PONG才说明协议通 - 执行
redis-cli -c -h 10.0.1.1 -p 6379 cluster nodes，检查输出里有没有fail、noaddr或大量connected状态为0的节点 - 确认集群节点间端口互通（不只是客户端能连），否则
CLUSTER SLOTS请求失败，启动时报redis: cluster supports only redis v3.0+这类误导性错误 - 在 Go 日志中加钩子：
client.AddQueryHook(&redis.QueryHook{Log: log.Printf})，看实际请求打到了哪个节点、是否被重定向
真正容易被忽略的点是：集群节点之间也得能互相通信。很多部署只开了客户端访问端口，忘了开放集群总线端口（通常是 redis 端口 + 10000），结果客户端能连，但拓扑拉不全，后续所有操作都不可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
