应优先在批量写入≥10条且命令可并行、允许部分失败时使用rdb.Pipeline()，如用户注册、排行榜更新；它非事务，不保证原子性，Exec()后需逐个调用.Result()检查各命令结果，单条或链式依赖场景应避免。
能提，但得看场景——批量写入 ≥10 条时，pipeline 通常能带来 3–5 倍吞吐提升；单条或读多写少时反而可能拖慢。
什么时候该用 rdb.Pipeline()？
核心判断依据是「命令是否可并行、是否允许部分失败」：
- 适合：用户批量注册、日志打点、排行榜更新（
ZAdd）、缓存预热（Set+Expire） - 不适合：依赖上一条结果的链式操作（比如先
Get再Set）、强一致性写（如扣库存必须原子）、单次或 ≤3 条命令 - 特别注意：
rdb.Pipeline()不是事务，Exec()返回的err只表示网络或协议错误，不反映某条命令执行失败（比如SET到只读实例会静默失败）
pipe.Exec() 后怎么拿到每条命令的结果？
返回值是 []redis.Cmder，需按添加顺序逐个调用 .Result() 解包。常见错误是直接用 interface{} 断言或忽略错误：
- 正确做法：对每个
Cmder显式检查Err()，再取值。例如incrCmd := pipe.Incr(ctx, "counter")，之后用val, err := incrCmd.Int64() - 陷阱：如果某条命令语法错（如 key 名含空格），
Exec()仍返回nil，但对应Cmder.Err()非空——不检查就 panic - 简化写法：用
pipe.TxPipeline()替代（它底层带WATCH，有原子性但性能略低），或改用原生命令如MSet/MGet（它们天然批量，无需 Pipeline）
为什么加了 Pipeline 反而变慢甚至阻塞其他请求？
根本原因是「大包压垮 Redis 单线程」——一次发几百条命令，Redis 必须串行执行完才响应，期间其他客户端的请求全在排队：
- 典型现象：Pipeline 写入时，监控看到
latency突增、get请求max_latency超过 100ms - 解法不是“不用”，而是“分片+节流”：每批控制在 50–100 条以内；写入密集时，在
Exec()后加time.Sleep(1 * time.Millisecond)让出 CPU - 生产建议：用
for i := 0; i 切分批次，避免单次发送超 1MB（Redis 默认proto-max-bulk-len是 512MB，但网络栈和 client buffer 容易溢出）
真正难的是权衡：Pipeline 的收益来自减少 RTT，但代价是放大单次执行的延迟毛刺。线上跑之前，务必用真实数据量 + redis-cli --intrinsic-latency 10 测本机延迟基线，再对比 pipeline 分批大小对 P99 的影响。
