system.io.pipelines 不适合直接用于文件io，专为网络流设计；强行套用会降低性能、引发内存泄漏或数据丢失，因其背压机制与文件io的随机访问、系统缓存特性不兼容。
System.IO.Pipelines 不适合直接用于文件 IO，强行套用反而降低性能、增加出错风险。 它是为网络流（如 Socket、HttpRequestStream）设计的零拷贝缓冲抽象，和文件读写在底层语义、调度模型、内存生命周期上根本不同。
为什么 PipeReader 不能直接包装 FileStream？
常见错误是试图这样写：new PipeReader(new FileStream(...)) 或把 PipeWriter 直接连到 FileStream 上。结果要么编译失败，要么运行时卡死、数据“丢失”、内存泄漏。
-
FileStream是同步/异步混合模型，而PipeReader要求生产者主动推进、消费者显式AdvanceTo，两者状态机不兼容 -
Pipe内部依赖内存池（MemoryPool<byte></byte>）做缓冲区复用，但FileStream.ReadAsync的内存生命周期由调用方完全控制，Pipe 无法接管 - 文件读取天然支持随机访问、预读、系统页缓存，而 Pipelines 的背压机制在网络场景有用，在磁盘 IO 中只会引入无谓等待
想复用 PipeReader 解析逻辑处理本地文件怎么办？
只在已有成熟协议解析器（比如一个基于 ReadOnlySequence<byte></byte> 的帧解码器），又想拿它跑测试或离线分析文件时，才考虑桥接——且必须手动控制内存，避免 double-copy。
- 用
FileStream.ReadAsync(Memory<byte>, ...)</byte>读入MemoryPool<byte>.Shared.Rent()</byte>的缓冲区 - 构造
ReadOnlySequence<byte></byte>时传入buffer.Memory.Slice(0, bytesRead)，不是buffer.Memory全量 - 调用
pipe.Writer.WriteAsync(sequence)后，不能立刻Return；要等下游ReadAsync完成并调用AdvanceTo后，再在consumed位置之后安全释放 - 别跨线程复用同一块
Memory<byte></byte>，也不要在未完成WriteAsync前重复调用Rent()
PipeOptions 配置对文件桥接毫无意义
像 new PipeOptions(pool: ..., minimumSegmentSize: 4096) 这类设置，只影响 Pipe 自己管理的内部缓冲区。当你手动把文件数据推入管道，这些配置不会改变读取行为，也不会提升文件吞吐——因为瓶颈从来不在 Pipe 缓冲区大小，而在磁盘带宽、系统缓存命中率和 FileStream 的 FileOptions 设置。
- 真正影响文件性能的是：
FileOptions.Asynchronous | FileOptions.SequentialScan - 缓冲区大小建议设为 128KB（
131_072），而非默认 4KB，减少系统调用次数 - 优先用
ArrayPool<byte>.Shared</byte>替代MemoryPool<byte>.Shared</byte>，前者专为短时批处理优化，后者偏向长期持有
最常被忽略的一点：Pipelines 的价值在于解耦「接收」和「解析」，但文件是静态载体，没有背压需求。硬套 Pipeline 模型，等于给拖拉机装 F1 空气动力套件——结构上能装，但既不减重，也不提速，还容易散架。
