Redis Pipeline 是将多个命令批量发送以减少RTT的优化机制，Go中用go-redis/v9的Pipeline()方法实现，需调用Exec()触发并逐个取Cmd结果，适用于无依赖批量操作。
Redis Pipeline 是什么，为什么 Go 里要用它
Go 客户端（比如 github.com/go-redis/redis/v9）默认每次调用 Set、Get 都发一个 TCP 包，网络往返（RTT）是主要瓶颈。Pipeline 把多个命令攒在一起发过去，服务端顺序执行再一次性回包，能省掉 N−1 次 RTT —— 尤其在高延迟网络或大批量操作时，提速常达 3–10 倍。
但要注意：Pipeline 不是事务，不保证原子性；出错时部分命令可能已生效，得自己处理幂等或回滚。
go-redis/v9 怎么写 Pipeline（不是 TxPipeline）
go-redis 的 Pipeline 和 TxPipeline 容易混淆。普通批量读写用 Pipeline()，它只打包命令、不加 WATCH；TxPipeline() 才走 Redis 事务流程（带 MULTI/EXEC），性能反而更低，别误用。
实操要点：
立即学习“go语言免费学习笔记（深入）”；
- 调用
client.Pipeline()获取pip对象，所有命令都链式调用在它上面 - 最后必须调
pip.Exec(ctx)触发实际发送，否则命令不会执行 - 每个命令返回一个
*redis.Cmd或*redis.StringCmd等，结果要从这些 cmd 对象里取，不是直接返回值
示例：
pip := client.Pipeline()
cmd1 := pip.Set(ctx, "key1", "val1", 0)
cmd2 := pip.Get(ctx, "key2")
_, err := pip.Exec(ctx) // 必须这一步
if err != nil {
// 处理 pipeline 级错误（如网络断开）
}
val, err := cmd2.Result() // 单个命令的结果要单独取
哪些场景适合 Pipeline，哪些不适合
Pipeline 适合「命令之间无依赖、可乱序执行」的批量操作，比如：缓存预热、日志聚合写入、批量 ID 查询。
不适合的情况：
- 下一个命令依赖上一个结果（例如先
INCR再根据值做判断）—— 得拆成多次调用或改用 Lua 脚本 - 命令数量极少（
- 涉及大 key（如 >10KB 的 value），打包后单次请求过大，可能触发 Redis 的
proto-max-bulk-len限制或客户端内存压力
容易踩的坑：错误处理、超时、连接复用
Pipeline 的错误不是“某个命令失败”，而是整批命令执行完后统一返回错误，或者部分命令成功部分失败（比如中间某条命令语法错，后面仍继续执行）。你得检查每个 Cmd.Err()，不能只看 Exec() 的 error。
其他关键点：
-
ctx超时对整个 Pipeline 生效，不是每条命令独立超时；设太短会整批中断，太长又拖慢故障恢复 - Pipeline 不自动重试，遇到
redis.Nil或网络错误需自行判断是否重放整批 - 别在 long-running goroutine 里复用同一个
Pipeline实例，它不是并发安全的；每次批量操作都应新建
真正麻烦的是混合错误类型：网络层失败（context deadline exceeded）、Redis 层失败（ERR wrong number of arguments）、业务逻辑失败（redis.Nil）得分开应对，这里没抽象层兜底，全得你写清楚。
