pipeline 不需 defer 关闭，因它仅为命令收集器，不持有连接资源；必须调用 exec() 才真正执行，且须逐个检查 cmder.err() 后再取值，避免 panic。
为什么 go-redis/v8 的 Pipeline 不能直接在 Gin handler 里用 defer 关闭？
因为 Pipeline 不是连接对象，而是临时构建的批处理上下文，它不持有底层连接资源，也不需要显式 Close()。常见错误是把 Pipeline 当成 redis.Client，试图 defer pipeline.Close() —— 这会编译报错：cannot call pointer method on pipeline 或运行时报 nil pointer dereference。
真正要关注的是：Pipeline 必须调用 Exec() 才会真正发请求；漏掉这一步，操作就静默丢失了。
-
Pipeline是轻量级的命令收集器，内部用 slice 缓存命令，不涉及连接池管理 - 每个
pipeline.Exec(ctx)会复用当前redis.Client的一个连接（从连接池取），执行完自动归还 - 不用 defer，但必须检查
Exec()的返回值，否则网络失败或 Redis 拒绝执行时你完全不知道
pipeline.Exec() 返回的 []redis.Cmder 怎么安全取结果？
GoRedis 的 Pipeline 执行后返回一个 []redis.Cmder 切片，每个元素对应一条命令的结果，但类型是接口，必须显式转型。直接用 .Val() 前没做 Err() 检查，会导致 panic。
典型场景：批量 GET 多个 key，其中部分 key 不存在或类型错误。
- 永远先调
cmd.Err() == nil再取值，比如cmd.(*redis.StringCmd).Val() - 对
INCR、HGETALL等不同命令，要匹配对应的具体 Cmd 类型（*redis.IntCmd、*redis.MapStringStringCmd） - 推荐用
redis.NewCmd()构造泛型命令，避免硬编码转型，尤其在混合命令管道中更安全
示例：
pipe := rdb.Pipeline()
get1 := pipe.Get(ctx, "user:1001")
get2 := pipe.Get(ctx, "user:1002")
incr := pipe.Incr(ctx, "counter:total")
_, err := pipe.Exec(ctx)
if err != nil {
// 处理整体管道错误（如网络中断）
return
}
// 单条命令仍可能失败
if get1.Err() != nil {
// key 不存在或类型不对
}
name1 := get1.Val() // 此时才安全
if incr.Err() != nil {
// 计数器操作失败
}
count := incr.Val()
Gin handler 中并发用 Pipeline 会不会抢连接？
不会。go-redis 的 Client 默认使用连接池（PoolSize 默认 10），Pipeline.Exec() 会从池中取一个连接执行整组命令，执行完立即释放。即使 100 个请求同时进 handler 并各自建 pipeline，只要连接池够大，就不会排队等待。
但要注意：Pipeline 本身不提升吞吐上限，只是减少 RTT。如果单次 Pipeline 包含 100 条命令，而连接池只有 2，高并发下反而可能因连接争抢拖慢整体响应。
- 默认
PoolSize对中小流量够用；写密集场景建议设为 CPU 核数 × 4～8 - 不要在一个 handler 里反复新建
Client实例，否则每个 client 都有独立连接池，浪费资源 - 若需更高吞吐，优先考虑用
TxPipeline()（事务型 pipeline），它能保证原子性且复用连接更高效
哪些操作不适合放进同一个 Pipeline？
Pipeline 要求所有命令在同一连接上顺序执行，所以依赖前序命令结果的逻辑不能塞进去 —— 比如「先 GET 再根据值决定是否 SET」这种条件分支，必须拆开。
另外，Pipeline 不支持跨 DB 切换（SELECT）、不支持订阅（SUBSCRIBE）、不支持阻塞命令（BLOCK 类）。
- 含
WATCH/MULTI的事务逻辑，必须用Client.TxPipelined()替代普通Pipeline() - 混合读写命令时，注意 Redis 的响应顺序严格按发送顺序，别指望后发的
GET能拿到前面SET的效果（它确实能，但仅限当前 pipeline 内） - 大量小 key 批量操作（如 1w 个
GET）建议分片，每 100～200 条一组 pipeline，避免单次 payload 过大触发 Redis 的 maxmemory 或 net buffer 限制
真正容易被忽略的点是：Pipeline 的错误隔离粒度是整条管道。一个命令失败（如 key 类型错误），不影响其他命令执行，但你得自己遍历所有 Cmder 检查 Err() —— 没人替你做这件事。
