go-redis.Pipeline在批量命令≥10条且RTT显著时才真正起作用，本地回环下小批量无收益；需显式调用Exec()触发发送，且必须逐个检查各命令Result()及Err()，不可仅依赖Exec()返回的error。
go-redis.Pipeline 什么时候真正起作用？
pipeline 不是“用了就快”，它只在命令量 ≥10 条、且网络 rtt 显著（比如跨机房、云厂商不同可用区）时，才能稳定带来 3–5 倍 qps 提升。本地回环（127.0.0.1）下，10 条以内命令用不用 pipeline 差异微乎其微，甚至因额外对象分配略慢。
常见误判场景：
- 单条
GET+ 单条INCR就包进Pipeline()→ 白费力气，还增加内存分配 - 每轮只塞 2–3 个命令，但高频调用（如每秒 1000 次）→ 实际仍是 2000–3000 次小包，RTT 没省下来
- 命令之间有强依赖（比如后一条要用前一条的返回值）→
Pipeline无法满足，必须用TxPipeline或 Lua
怎么写才不踩坑：Pipe.Exec() 的返回值和错误处理
pipe.Exec(ctx) 返回的是 []interface{} 和 error，这个 error 只表示“网络发送失败”或“Redis 连接中断”，**不反映任何单条命令是否执行成功**。哪怕第 1 条 SET 语法错、第 5 条 ZADD key 不存在，只要 TCP 包发出去了，Exec() 就返回 nil 错误。
正确做法是检查每个结果项：
- 用类型断言提取具体返回，比如
result[0].(string)或result[1].(int64) - 对可能出错的命令（如
HGetAll、ZRange），要判断result[i] == nil或是否为redis.Nil - 不要依赖
err != nil判断业务逻辑失败；redis.Nil是合法响应，不是错误
示例片段：
SET
- 如果 key 分布极散（如 user:1001、order:9999、cache:abc），Redis 内存访问局部性差，CPU cache miss 上升，反而抵消 RTT 节省
- 大体积 value（如 >10KB 的 JSON）批量读会撑满 socket buffer，触发 TCP 拆包重传，延迟反弹
- 推荐策略：读操作优先用
MGET/HMGET等原生命令；只有当必须混用不同类型命令（比如 GET + INCR + EXPIRE）时，再上 Pipeline
别忽略连接池配置：Pipeline 效果被 PoolSize 卡住
即使 Pipeline 把 100 条命令压成 1 次发，如果 PoolSize 只有 10，而并发请求达到 50，那这 50 个 Pipeline 请求仍要排队抢连接 —— 最终变成 5 批 × 每批 10 条，RTT 节省打五折。
生产环境关键参数建议：
-
PoolSize：设为预估峰值 QPS ÷ 单次 Pipeline 平均命令数 × 1.5（例如 QPS=3000，每批 20 条 →PoolSize=225） -
MinIdleConns：设为PoolSize的 20%，避免突发流量时频繁建连 -
ConnMaxIdleTime：设为 5m，防止长连接在负载下降后持续占用资源
漏掉这点，Pipeline 再精巧也跑不满网卡。
