await foreach 要求 IAsyncEnumerable，FileStream 不实现该接口，故不能直接使用；需通过 File.ReadLinesAsync()、手动封装异步迭代器（注意 MemoryPool 管理与 CancellationToken 传递）或第三方库实现，且须确保底层 Stream 真异步（如指定 FileOptions.Asynchronous）。
async foreach 要求 IAsyncEnumerable，FileStream 本身不直接提供
你不能直接 await foreach 一个 FileStream，它不实现 IAsyncEnumerable<byte></byte>。常见错误是写成：await foreach (var b in fileStream)——编译不过，报错：foreach statement cannot operate on variables of type 'FileStream' because 'FileStream' does not contain a public instance definition for 'GetAsyncEnumerator'。
真正能用 await foreach 的，是像 File.ReadLinesAsync()（C# 12+）、Stream.ReadAsync 手动封装的迭代器，或第三方库（如 Microsoft.IO.RecyclableMemoryStream 配合自定义异步枚举器）。
- 最常用场景：逐行读取大文本文件，避免一次性加载进内存
-
File.ReadLinesAsync(string)返回IAsyncEnumerable<string></string>，但注意它只在 .NET 6+ 可用，且底层仍基于StreamReader+ReadLineAsync() - 若需按块读取二进制流（比如解析日志、分片上传），得自己写异步迭代器方法，返回
IAsyncEnumerable<memory>></memory>
手动实现 IAsyncEnumerable> 的关键点
自己封装异步迭代器时，核心是用 yield return + await，但必须放在返回 IAsyncEnumerable<t></t> 的方法里，且该方法需标记 async 和 yield 共存（C# 8+ 支持）。
典型坑：在 while 循环里反复 await stream.ReadAsync(buffer) 后直接 yield return buffer.AsMemory(0, read)——这会出错，因为 buffer 是复用的，下次读取会覆盖内容。必须拷贝或用 MemoryPool<byte>.Shared.Rent()</byte> 管理生命周期。
- 推荐用
MemoryPool<byte>.Shared.Rent(int)</byte>分配独立内存块，读完后yield return对应的Memory<byte></byte> - 别忘了在
finally或using中rent.Return()，否则内存泄漏 - 缓冲区大小建议设为 4096 或 8192，太小增加调度开销，太大浪费内存
- 示例片段：
async IAsyncEnumerable<Memory<byte>> ReadChunksAsync(Stream stream, int bufferSize = 8192) { var pool = MemoryPool<byte>.Shared; var rent = pool.Rent(bufferSize); try { int read; while ((read = await stream.ReadAsync(rent.Memory)) > 0) { yield return rent.Memory[..read]; } } finally { rent.Return(); } }
await foreach 中异常处理和取消支持不能省
await foreach 不会自动传播 CancellationToken 到底层迭代器，也不捕获迭代过程中的异常——除非你显式传入并检查。常见现象：按下 Ctrl+C 或超时后，读取卡住、资源未释放、任务永不结束。
正确做法是在异步迭代器方法签名里加 CancellationToken token = default，并在 ReadAsync 调用中传入；同时在 await foreach 外层用 try/catch 包裹，因为 MoveNextAsync() 抛异常会终止循环。
-
stream.ReadAsync(buffer, token)是唯一能响应取消的读取方式，裸调ReadAsync(buffer)忽略取消信号 - 如果迭代器内部用了
Task.Delay或其他异步操作，也必须传入token - 异常发生时，
await foreach会立即退出，但rent.Return()如果在finally外，可能漏掉——所以务必把资源清理逻辑放进finally
.NET 版本和 Stream 实现差异影响实际行为
await foreach 能否高效工作，取决于底层 Stream 是否真正异步。比如 FileStream 在 Windows 上默认启用 FileOptions.Asynchronous 才走 IOCP，否则 ReadAsync 只是线程池模拟，反而更慢。
另一个易忽略点：某些 Stream 子类（如 BufferedStream、GzipStream）对 ReadAsync 的实现不保证完全异步，甚至可能同步阻塞。调试时看到 CPU 占用高、延迟大，大概率是这个原因。
- 创建
FileStream时显式指定：new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, 4096, FileOptions.Asynchronous) - 避免嵌套包装：比如
new GzipStream(new BufferedStream(fileStream))，多层同步 fallback 会让异步失效 - .NET 5+ 中
FileStream默认启用异步，但旧项目若 Target Framework 是 .NET Core 3.1，仍需手动确认FileOptions
实际用起来，最麻烦的不是语法，而是内存生命周期管理和底层 Stream 是否真异步——这两处一错，要么 OOM，要么性能还不如同步读。
