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 反而多花在复制上。
