Redis Cluster不支持传统Pipeline，因协议限制多key命令须同slot，客户端会panic或降级；可行方案是手动路由至同slot节点调用Pipeline，或用MGET等原生集群命令。
Redis Cluster不支持传统Pipeline
直接说结论：Go 客户端（如 github.com/go-redis/redis/v9）对 Redis Cluster 调用 Pipeline() 或 TxPipeline() 时，会 panic 或静默降级——因为 Redis Cluster 协议本身不允许多 key 命令跨 slot 打包发送，服务端根本不识别 PIPELINE 这个概念。
常见错误现象：ERR CROSSSLOT Keys in request don't hash to the same slot（即使你没显式写跨 slot 操作，Pipeline 内部可能被自动路由到不同节点）；或客户端直接报 redis: cluster pipeline is not supported。
- 根本原因：Pipeline 是单节点 TCP 层的优化机制，Cluster 是分片架构，每个命令必须先算 slot、再发往对应节点，无法统一打包
- 不是 Go 客户端的 bug，是 Redis 协议限制；哪怕用
redis-cli -c也做不到真正的 Cluster Pipeline - 如果你的 key 都落在同一个 slot（比如加了
{...}tag），理论上可以走单节点 Pipeline，但客户端通常不保证这点，也不推荐依赖
用 WrapProcess + Cmdable 手动聚合请求
真正可行的“类 Pipeline”方案，是利用 go-redis/v9 的 WrapProcess 钩子，在命令执行前把多个同 slot 的命令攒起来，批量发给目标节点。这需要你控制 key 的分布，并自己做路由预判。
使用场景：已知一批 key 属于同一哈希槽（例如都带 {user:123} 前缀），且操作都是读或都是写，不涉及事务语义。
立即学习“go语言免费学习笔记（深入）”；
- 步骤一：用
clusterClient.KeySlot("{user:123}:profile")算出 slot - 步骤二：通过
clusterClient.Nodes()找到负责该 slot 的节点（*redis.Client） - 步骤三：在该节点上直接调用
node.Pipeline()，像单机一样使用 - 注意：不能混用不同 slot 的 key，否则节点会拒绝；也不能在 Pipeline 中调用
EXEC或EVAL这类集群不兼容命令
替代方案：用 MGET/MSET 等原生命令
对批量读写，优先用 Redis 原生支持集群的多 key 命令，它们内部已做 slot 校验和分发，比模拟 Pipeline 更稳更快。
性能影响：相比单条命令，MGET 减少网络往返，但仍是单次 round-trip；而真 Pipeline 在单机上可压成一个 TCP 包，延迟更低——所以集群下性能上限天然低一截。
-
MGET key1 key2 key3：所有 key 必须在同一 slot，否则报CROSSSLOT - 安全写法：用
{user:123}:name、{user:123}:email确保同 slot -
DEL、EXPIRE也支持多 key，但INCR、HGET等不支持——别硬套 - go-redis 中直接调
client.MGet(ctx, "{u:1}:a", "{u:1}:b")，返回[]interface{}，需自行类型断言
为什么不用 TxPipeline 或 Lua 脚本
有人想用事务或脚本来“绕过”限制，但实际踩坑更多。
常见错误现象：Lua 脚本里用 redis.call("GET", KEYS[1], KEYS[2]) 报 CROSSSLOT；TxPipeline 在 Cluster 模式下被自动禁用，调用后返回空结果或 panic。
- Redis Cluster 对 Lua 的要求更严：所有
KEYS必须落在同一 slot，且脚本不能包含redis.replicate_commands()以外的写操作 -
TxPipeline底层仍依赖 Pipeline 机制，go-redis/v9 明确文档写明 “not supported in cluster mode” - 如果真要强一致性批量操作，唯一办法是把数据收拢到一个 slot（牺牲扩展性），或改用单节点 Redis（放弃高可用）
真正麻烦的地方不在代码怎么写，而在设计阶段就要决定：这批 key 是否必须共存于一个 slot。一旦上线，改 key 结构成本很高。
