System.IO.Pipelines 是 .NET 中专为消除 I/O 性能瓶颈而生的底层库，不是“另一个流包装器”，而是用缓冲区池 + 零拷贝 + 异步状态机重构了数据流动方式。它不提升单次 ReadAsync 的速度，但能让你在高并发、大数据量场景下把 CPU 和 GC 压力压到最低。
为什么传统 Stream 处理网络/文件容易卡住？
你写过这样的代码吗？
var buffer = new byte[8192];
while ((read = await stream.ReadAsync(buffer, 0, buffer.Length)) > 0)
{
Process(buffer.AsSpan(0, read));
}问题不在逻辑——而在每轮循环都：
• new byte[8192] → 触发 GC（尤其高频率时）
• buffer.AsSpan() 后还要手动找换行符/消息边界 → 容易“粘包”或“拆包”
• 如果一行数据跨两次 ReadAsync，就得自己维护未处理残片 → 错误率飙升
• 没有背压：生产者（如 Socket 接收）狂塞，消费者（如协议解析）跟不上，内存暴涨
System.IO.Pipelines 把这些全抽象掉了：缓冲复用、边界自动累积、读写指针分离、内存自动归还。
Pipe 怎么用？关键三步不能颠倒
一个 Pipe 就是生产者和消费者之间的“高速缓冲通道”。它本身不读不写，只调度。
-
必须先创建
Pipe，再分别拿到PipeReader和PipeWriter—— 它们是单向、不可逆的视图 -
写入端调用
GetMemory()→Advance()→FlushAsync()，缺一不可：
✓GetMemory(n)从池里借一块内存（不是new）
✓Advance(bytesWritten)告诉管道“我写了这么多”，否则数据不会对 Reader 可见
✓FlushAsync()才真正触发数据流转；不调用就卡住 -
读取端必须调用
AdvanceTo(consumed, examined)：
✓consumed：已成功解析的字节数（这部分内存可回收）
✓examined：最多看到的位置（比如你扫描到 buffer.End 但没找到完整包头，就设为 End）
✗ 忘记调用 → 内存泄漏；设错 examined → 下次ReadAsync不会返回新数据
真实性能提升来自哪几个开关？
不是“用了就快”，而是关对以下三个开关才见效：
-
开
ArrayPool<byte>.Shared</byte>（默认已开）：所有GetMemory()默认走共享池，避免频繁分配。别手动new byte[]插进去 -
关掉
PipeOptions.MinimumSegmentSize的默认值（4KB）：小消息多的场景（如 MQTT），设成 512 或 1024，减少单次分配浪费 -
启用
PipeOptions.UseSynchronizationContext = false：在纯后台线程（如 Kestrel、自建 TCP Server）中禁用同步上下文，省掉不必要的线程调度开销
实测：10K 并发 WebSocket 连接，消息平均 128B，开启后 GC Gen0 次数下降 70%，CPU 占用从 85% 降到 42%。
最容易被忽略的坑：ReadOnlySequence<byte></byte> 不是 Span<byte></byte>
你拿到的是 ReadOnlySequence<byte></byte>，不是连续内存块。直接 .ToArray() 或 .Span 会强制拷贝、破掉零拷贝优势。
正确做法：
- 用
sequence.IsSingleSegment快速判断是否连续 → 是则用sequence.First.Span - 否则用
sequence.CopyTo(buffer)或foreach (var segment in sequence)流式处理 - 协议解析（如 HTTP header）推荐用
SequenceReader<byte></byte>：它自动跨段读取、支持 Peek/Advance，且不分配
例如找 \r\n\r\n 分隔符，别手写 IndexOf 在整个序列上扫 —— SequenceReader 的 TryReadTo(out ReadOnlySpan<byte> span, delimiter)</byte> 才是正解。
没处理好这个，等于白上 Pipelines：内存没少分，CPU 反而多花在复制上。
