.NET 不提供 File.ReadLinesAsync 方法，应使用 StreamReader.ReadLineAsync 手动构建 async IAsyncEnumerable，注意 ConfigureAwait(false)、编码显式指定、取消令牌、异常处理及资源释放时机。
为什么不能直接用 File.ReadLinesAsync
因为 .NET 原生不提供 File.ReadLinesAsync —— 这个方法根本不存在。有人误以为它存在，结果编译报错 CS1061：“File 不包含 ReadLinesAsync 的定义”。真正可用的是 File.ReadAllLinesAsync，但它会把整个文件一次性读进内存，对 GB 级文件直接 OOM。
用 StreamReader.ReadLineAsync 手动构建 IAsyncEnumerable<string></string>
核心思路：在 async IAsyncEnumerable<string></string> 方法里循环调用 streamReader.ReadLineAsync()，每次 yield return 一行。注意必须用 ConfigureAwait(false) 避免上下文捕获开销，尤其在无 UI 的后台服务中。
示例：
async IAsyncEnumerable<string> ReadLinesAsync(string path)
{
await using var stream = File.OpenRead(path);
await using var reader = new StreamReader(stream, Encoding.UTF8);
string? line;
while ((line = await reader.ReadLineAsync().ConfigureAwait(false)) != null)
{
yield return line;
}
}
- 别用
new StreamReader(path)—— 它内部会同步打开文件，阻塞线程 - 显式传入
Encoding，避免 BOM 或编码不一致导致首行乱码 - 不要在循环里
await usingStreamReader，会导致每次迭代都新建/释放资源
处理超大文件时的内存与异常边界
IAsyncEnumerable 本身不缓冲整文件，但消费者（比如 await foreach）若处理慢，上游仍可能积压未消费的行 —— 实际上取决于底层 Channel 的实现和是否启用 WithCancellation。
- 务必加取消令牌：
await foreach (var line in ReadLinesAsync(path).WithCancellation(ct))，否则Ctrl+C或超时无法中断读取 - 遇到二进制垃圾或编码错误时，
StreamReader默认抛IOException或DecoderFallbackException，建议在外层try/catch并记录原始字节偏移（用stream.Position） - 如果文件含空行或超长行（如日志中嵌 JSON），需自行限制单行长度，否则可能被恶意构造的超长行拖垮内存
比手写更稳的选择：Microsoft.IO.RecyclableMemoryStream + 自定义异步流
纯 StreamReader 在高频小行场景下，每行分配 string 会造成 GC 压力。若性能敏感（如解析千万行日志），可配合 RecyclableMemoryStreamManager 复用缓冲区，再用 Memory<byte></byte> + Encoding.GetString() 解码 —— 但这要求你手动处理换行符（\n、\r\n）、BOM、不完整行等细节。
简单项目不推荐过早优化；但若已观察到 Gen2 GC 频繁或 string 占用堆顶，这个路径才值得投入。
真正容易被忽略的是：异步流的 dispose 行为。即使 await foreach 提前退出（如 break 或异常），yield return 方法体末尾的 await using 仍会执行 —— 但前提是没在 yield 后抛出未处理异常。任何在 yield return 之后、await using 之前的异常，都会跳过资源释放。
