异步文件处理必须用显式启用FileOptions.Asynchronous的FileStream而非默认FileStream或工厂方法；管道节点应统一返回ValueTask以减少GC压力；插拔式设计宜采用Func函数链，中间流须设leaveOpen:true，全程由最外层统一释放资源。
异步文件处理必须用 Stream 而不是 FileStream 直接 await
很多人一上来就写 await fileStream.ReadAsync(...)，结果发现卡主线程或吞吐掉得厉害——根本原因是没理解 FileStream 默认不开启异步 I/O。Windows 上它底层走的是同步模拟（APC 模式），Linux/macOS 更是直接退化成同步阻塞。
真正可伸缩的异步链，起点必须是显式启用异步支持的 FileStream 构造：
- 构造时传入
FileOptions.Asynchronous（Windows 必须，.NET 6+ 在 Linux/macOS 也建议加上） - 避免用
File.OpenRead(path)这类工厂方法，它们默认不带Asynchronous - 别在
using var fs = new FileStream(...)里混用同步和异步方法，容易触发隐式同步回退
示例正确打开方式：
var fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, 4096, FileOptions.Asynchronous);
责任链节点必须返回 ValueTask<t></t> 而非 Task<t></t>
文件管道常被高频调用（比如日志归档、上传中转），每一步都 new Task 会快速堆积 GC 压力。而 ValueTask<t></t> 在多数路径下能复用对象、避免堆分配。
但注意：只有当你确定节点逻辑绝大多数时候是同步完成（如内存解码、头信息校验），或者内部已用 ValueTask 包装了底层 I/O（如 MemoryStream.ReadAsync），才适合暴露 ValueTask。
- 不要把
async Task<t> DoX()</t>简单改成async ValueTask<t> DoX()</t>—— 编译器仍会生成Task状态机 - 真正要改的是：用
return new ValueTask<t>(result)</t>或return _innerStream.ReadAsync(...)（后者由Stream实现决定是否复用） - 链上所有节点类型必须统一，混用
Task和ValueTask会导致await无法推导，编译报错
插拔式设计靠 Func<stream valuetask>></stream> 而非接口继承
想加个压缩环节？再加个加密？用传统接口（IFileProcessor）会逼你为每个环节写新类、注册、维护生命周期。实际文件流是线性传递的，函数签名就是最轻量契约。
定义管道核心类型：
public record FilePipeline(Func<Stream, ValueTask<Stream>>[] Steps);
- 每个步骤接收前序输出的
Stream，返回处理后的Stream（可以是新实例，也可以是原实例 + 内部状态变更） - 避免在步骤里
Dispose输入流——责任链不负责资源释放，交给最外层调用者 - 若某步骤需提前终止（如校验失败），抛出异常即可；不要返回
null流，那会引发后续NullReferenceException - 调试时可在任意步骤包一层日志：
s => { Log("decrypting..."); return DecryptAsync(s); }
容易被忽略的流生命周期陷阱
异步链跑着跑着 ObjectDisposedException，十有八九是某个环节偷偷把流关了，或者多个步骤并发读同一份流。
-
MemoryStream是线程安全的读，但FileStream不是——别让两个并行步骤同时ReadAsync同一个FileStream - 所有中间
Stream（如GzipStream、CryptoStream）必须设置leaveOpen: true，否则Dispose会连带关闭上游 - 最终输出流如果要保存到磁盘，别用
CopyToAsync(dest)后直接Dispose源流——应确保CopyToAsync完成后再释放，否则可能丢尾部数据
最稳的做法：整个链用同一个 Stream 实例贯穿，只在必要环节包装（如 new CryptoStream(inner, ..., CryptoStreamMode.Read) { leaveOpen = true }），最后由调用方统一 Dispose。
