必须显式调用pipe.execute()，因为Pipeline仅缓存命令于客户端内存，不调用则命令永不发送、数据丢失；重复调用会panic，且每条命令错误需单独检查Cmd.Err()。
pipeline 能把 N 次网络往返压成 1 次，但用错方式不仅没提速，还可能丢数据、卡连接、触发 client-output-buffer-limit 断连。
为什么 pipe.execute() 必须显式调用
调用 r.pipeline() 只是创建一个缓冲对象，所有命令都堆在内存里，根本没发出去。常见错误是写了 pipe.set('x', 1) 就以为执行了，结果 key 根本没写进 Redis。
- 必须调用
pipe.execute()才真正打包发送并接收响应 - 推荐用
with r.pipeline() as pipe:—— 自动处理异常时的缓冲清空和资源释放 - 别链式调用
r.pipeline().set(...).get(...).execute()：可读性差，且一旦中间出错（比如类型不匹配），整个 pipeline 会中断，错误定位困难
哪些命令组合适合 pipeline，哪些会翻车
Pipeline 不是事务，也不检查语义依赖。它只保证命令按顺序发出、按顺序返回，但不保证“前一条的结果能喂给后一条”。
- 安全场景：
set+hset+lpush（key 不重叠、类型不冲突） - 危险操作：
get('user:1')后紧跟set('user:1', ...)—— 你拿不到get的返回值去构造下一个 key 或 value，Pipeline 内无法做条件分支 - 完全禁止：
watch、multi、eval—— 这些命令本身要求服务端状态同步，Pipeline 会直接报错或返回空响应
单次 pipeline 多大才合适
不是越长越好。过长的 pipeline 会撑爆 Redis 的输出缓冲区，也可能让一次失败导致整批重试成本飙升。
- 默认
client-output-buffer-limit是 256MB，超限连接会被强制断开 - 建议单次控制在 100–500 条命令之间，具体看每条响应大小（比如
lrange key 0 -1返回几 MB 数据，那 10 条就顶天了） - 批量导入时，用
redis-cli --pipe更稳——它自带分块和换行协议校验，比手写redis-pypipeline 更容错
怎么确认 pipeline 真正在起作用
别光看 instantaneous_ops_per_sec —— 它会虚高，因为客户端把一堆命令“塞”成一次发，Redis 记作一次 TCP 请求，但内部还是逐条执行。
立即学习“Python免费学习笔记（深入）”；
- 真瓶颈在客户端耗时：用
time.time()包住pipe.execute()看实际延迟 - 看网络指标：
net_input_bytes和net_output_bytes是否明显下降（说明减少了小包数量） - 警惕混入阻塞命令：
keys *、slowlog get、monitor—— 它们会让整个 pipeline 卡住等结果，拖垮吞吐
