FileStream 配 BufferedStream 会压垮内存，因其8KB缓冲区仅在写满时阻塞，而上游不等待导致数据持续涌入；需全程 await WriteAsync 实现端到端背压，禁用同步写与内部缓冲。
为什么 FileStream 直接配 BufferedStream 会压垮内存
因为默认的 BufferedStream 缓冲区是 8KB，但它的“背压”逻辑只在写满缓冲区时才触发阻塞——而上游（比如网络接收或高速传感器）根本不管这个节奏，数据照发不误。你看到的现象通常是：内存占用飙升、GC 频繁、甚至 OutOfMemoryException，但没报错，程序只是越来越慢。
真正起作用的不是加缓冲，而是让上游「等你写完再给下一批」。C# 里只有靠 WriteAsync 的 await 链才能把压力传导回去。
- 别用
new BufferedStream(fileStream)包裹高速写入流——它不提供背压语义，只是缓存加速 - 确保所有写操作都走
WriteAsync并await，不能丢掉 await 或退化成同步写 - 如果上游是
IAsyncEnumerable<byte></byte>或类似推送源，必须用await foreach+ 每次await stream.WriteAsync(...)，中间不能攒多块再写
StreamWriter 和 Stream 写法对背压的影响差异
StreamWriter 默认开启内部缓冲（4096 字节），且它的 WriteAsync 不保证立刻落盘——它先填内部 buffer，buffer 满了才调用底层 Stream.WriteAsync。这就断开了背压链：上游以为你收下了，其实数据还卡在 StreamWriter 的 buffer 里。
如果你需要端到端背压，就得关掉它的缓冲，或者绕过它直接操作 Stream。
- 关缓冲：
new StreamWriter(stream, Encoding.UTF8, bufferSize: 1, leaveOpen: true)—— bufferSize 设为 1 强制每次写都穿透到底层 - 更稳的做法：不用
StreamWriter，改用stream.WriteAsync(Encoding.UTF8.GetBytes(...))，自己控制编码和分块 - 注意
StreamWriter.FlushAsync()不解决背压——它只清空自己的 buffer，不等底层写完；真要等，得await stream.FlushAsync()（如果底层支持）
用 Channel<t></t> 手动控速时容易漏的关键点
有人用 Channel.CreateBounded 做生产者-消费者解耦，以为设了容量就能限流。但实际中常发现内存还是涨，原因在于：channel 的 “背压” 只作用于 Writer.TryWrite 或 Writer.WaitToWriteAsync，而如果你的生产者没检查返回值、也没 await 等待写入机会，就等于把 channel 当无界队列用了。
- 必须用
await writer.WaitToWriteAsync()+writer.TryWrite(...)组合，不能只靠TryWrite返回 false 就跳过——false 只表示瞬时失败，不代表后续不能写 - channel 容量设太小（比如 1）会导致频繁等待，设太大（比如 1000）又失去控速意义；建议按单次写入大小 × 期望最大延迟（如 200ms）反推，例如每块 64KB，目标延迟 200ms → 约 15 块 ≈ 容量 16
-
Channel.Reader.ReadAsync()必须在 consumer 中持续 await，不能用ReadAllAsync一次性读光——那会把所有数据拉进内存
Windows 上 FILE_FLAG_NO_BUFFERING 能不能缓解背压
不能。这个 flag 是绕过系统缓存，要求应用自己对齐 I/O（扇区对齐、长度对齐），但它不改变写入调用的同步/异步行为，也不提供任何流控机制。反而因为失去系统层缓冲，WriteFile 更容易阻塞，导致上层 await 停顿更久，放大背压抖动。
它适合大块顺序写、追求极致吞吐的场景，但和背压控制无关。真要降低延迟敏感度，优先调 FileStream 的 bufferSize 参数（比如设为 64KB），并确保 useAsync: true。
- 创建时显式指定：
new FileStream(path, FileMode.Create, FileAccess.Write, FileShare.None, bufferSize: 65536, useAsync: true) - 不要混用同步和异步方法——比如一边
Write一边WriteAsync，会破坏 I/O 完成端口调度，引发不可预测的阻塞 - .NET 6+ 中
FileStream默认 useAsync=true，但旧项目或跨平台部署时仍建议显式写出，避免环境差异
背压不是加个缓冲或开个 async 就能自动生效的机制，它是整个调用链上每一环都必须参与的协作协议。最容易被忽略的是：你以为的“异步写入”，可能卡在某一层的内部 buffer 里，而上游早已继续推送——那一瞬间，你已经在积累内存债务了。
