pipeline快是因为将100次rtt压缩为1次网络往返，实测跨机房耗时从1200ms降至90ms；正确写法是使用回调模式$redis->pipeline(function($pipe){...})，而非链式调用。
Hyperf里用 pipeline 批量写Redis为什么快
因为默认每次调用 $redis->set() 都会触发一次网络往返（RTT），100次写就是100次RTT；而 pipeline 把这100次命令打包成1次发送、1次接收，网络开销从100份降到1份。实测在跨机房场景下，耗时能从1200ms压到90ms左右。
正确写法：必须用 pipeline() 回调模式，别用链式调用
Hyperf的 Hyperf\Redis\Redis 实例不支持直接调用 $redis->pipeline()->set(...)->get(...)->exec() 这种Laravel风格——它没有返回可链式操作的Pipeline对象。必须用回调方式，否则会拿到空结果或报错。
-
$redis->pipeline(function ($pipe) { $pipe->set('a', '1'); $pipe->set('b', '2'); });✅ 正确，自动执行并返回结果数组 -
$redis->pipeline()->set('a', '1');❌ 错误，pipeline()不返回可链式对象，会抛Call to a member function set() on null - 回调内不能
return中断，否则后续命令不执行；异常需在回调外捕获
批量写入时怎么控制单次Pipeline大小
单次Pipeline塞500条命令看似爽，但容易触发Redis响应超时或客户端内存暴涨。Hyperf本身不限制，得自己切片。建议按100–200条/批分组，尤其在高延迟网络或大value场景下。
- 用
array_chunk($data, 100)拆分原始数据 - 每批单独进一个
pipeline()回调，避免单次阻塞太久 - 注意：Pipeline不是事务，某条命令失败（比如key过期、类型错误）不影响后续命令，错误结果会出现在返回数组对应位置，值为
false或RedisException对象
异常处理不当会导致Redis连接泄漏
这是最容易被忽略的坑。如果 pipeline 回调里抛出未捕获异常，Hyperf底层可能无法归还连接到连接池，持续泄漏最终拖垮服务。
- 务必把业务逻辑包裹在
try/catch内，且catch后显式释放资源（虽然Hyperf一般会兜底，但不保险） - 不要在回调里
throw new Exception，改用日志记录 + 返回标记值 - 生产环境建议加监控：观察
hyperf.redis.pool.connections.used指标是否缓慢上涨
真正难的不是写对语法，而是把“批量”和“可靠”捏在一起——既要切片防爆，又要兜住异常不漏连，还得让错误结果可定位。这些细节不压到线上跑几天，很难靠文档发现。
