必须手动分块读取 FileStream 并写入 PipeWriter：用 ReadAsync + GetMemory + Advance + FlushAsync 协同控制背压，读完后调 FlushAsync 再 CompleteAsync；禁用 CopyToAsync 和 StreamPipeReader，避免同步 I/O 卡死和内存管理失效。
怎么把 FileStream 接到 PipeWriter 上
不能直接塞，PipeWriter 不接受 Stream，它只认 ReadOnlyMemory<byte></byte> 或异步写入操作。你得自己读文件、分块送进去，再手动处理背压和完成信号。
常见错误是用 stream.CopyToAsync(pipe.Writer.AsStream()) —— 这会绕过管道的内存管理，丢失节流能力，还可能触发 InvalidOperationException：“PipeWriter has been completed.”
- 用
Pipe自带的Writer，别转成Stream再套一层 - 读文件用
FileStream.ReadAsync配合栈分配的Memory<byte></byte>（比如stackalloc byte[8192]），避免 GC 压力 - 每次
WriteAsync后必须调用FlushAsync，否则数据卡在内存里不出去 - 文件读完后要
await writer.CompleteAsync()，否则下游永远等不到IsCompleted为 true
为什么不能用 StreamPipeReader 包装 FileStream
StreamPipeReader 是为“可随时读取的流”设计的，比如网络流或内存流；而 FileStream 在某些场景下（如打开时没加 FileOptions.Asynchronous）会退化为同步 I/O，导致 StreamPipeReader 内部线程池卡死，出现高延迟或 TimeoutException。
- Windows 上默认创建的
FileStream若没显式传FileOptions.Asynchronous，即使调ReadAsync也可能是同步完成的 -
StreamPipeReader依赖底层流真正异步，否则它的内部缓冲策略会失效 - 实测中，大文件传输时吞吐量可能比手写循环低 30% 以上，因为多了一层拷贝 + 锁竞争
如何安全地边读文件边写 PipeWriter（含背压）
核心是把文件读取和管道写入做成一个协同节奏：读一块、等写完、再读下一块。靠 PipeWriter.GetMemory() 和 Advance() 控制内存生命周期，而不是预分配大 buffer。
var buffer = writer.GetMemory(8192); var read = await fileStream.ReadAsync(buffer, cancellationToken); if (read == 0) break; writer.Advance(read); await writer.FlushAsync(cancellationToken);
- 不要假设
GetMemory(n)一定返回 n 字节 —— 它可能更少，尤其管道快满时，得检查.Length - 每次
Advance()后必须FlushAsync()，否则GetMemory()下次可能返回 0 长度 - 如果文件很大，建议在循环里加
cancellationToken.ThrowIfCancellationRequested()，否则中断时CompleteAsync可能被跳过
PipeReader 消费端收不到 EOF？检查 Complete 调用时机
很多问题不是流没读完，而是 writer.CompleteAsync() 调早了：比如在 ReadAsync 返回 0 之后立刻 Complete，但上一批数据还没 Flush 完，导致下游 reader.ReadAsync() 先拿到数据、再等半天才收到 IsCompleted。
- 正确顺序是：
ReadAsync → if (0) { await writer.FlushAsync(); await writer.CompleteAsync(); } - 如果用了
try/finally做清理，确保CompleteAsync在FlushAsync之后，且不被异常跳过 - 下游用
while (!reader.IsCompleted)循环时，记得每次ReadResult后调reader.AdvanceTo()，否则管道内存不释放，很快 OOM
FlushAsync 的必要性 —— 它不像 Stream.Flush() 那样可选，而是管道数据流动的开关。漏掉一次，整个链路就卡住，还很难定位。 
