await调用WriteLineAsync写文件报文件占用IOException的原因

两种调用方式的行为差异 #

• await调用时的异常触发逻辑
  当使用await调用WriteLine方法时，代码会严格串行执行：每读取一行文本，就完整走完「打开文件→写入当前行→关闭释放文件句柄」的全流程，确认流程执行完成后才会进入下一轮循环。
  这个场景下抛出文件占用异常，核心原因是循环中反复打开、关闭output.txt，文件句柄刚释放的极短时间窗口内，系统自带进程（杀毒软件实时扫描、Windows搜索索引服务、资源管理器文件预览）会立刻抢占文件句柄做扫描/读取操作，下一轮循环打开文件时就会触发「文件被其他进程占用」的IOException。
• 不await调用时无异常的真相
  这种场景下程序没有报错不代表文件写入流程正常，本质是机制差异造成的假象：
  1. 未被await的异步任务抛出的异常会被默认吞掉：循环中直接调用WriteLine不等待，相当于发起了“发后不理”的后台任务，这些任务执行中哪怕触发了文件占用异常，因为没有被主线程观察（没有await、没有访问Task.Exception属性），异常不会中断主线程执行，只会在任务被GC回收时作为未观察异常触发，默认配置下这类异常不会导致程序崩溃。如果给这些任务加上异常观察逻辑，你会看到和await场景完全一致的占用异常。
  2. 感知上的“完整执行完所有读写流程”只是主线程的读循环跑完了，后台排队的写入任务实际大概率存在随机失败，只是没有被感知到。

代码本身的设计缺陷 #

当前写入逻辑本身存在不合理设计：逐行读取的循环中反复创建、释放StreamWriter，频繁开关文件本身就会大幅提升IO开销，同时极容易撞上系统进程占用文件的时间窗口，是触发异常的根本诱因。

• 最优方案是把StreamWriter的初始化移到循环外部，整个读循环过程中只打开一次文件，循环结束后再统一释放句柄，从根源上避免反复开关文件的问题，示例代码如下：

static async Task ProcessRead(StreamReader reader)
{
    string outputPath = "output.txt";
    // 循环外一次性打开写入流，显式指定文件共享模式提升可控性
    using (StreamWriter writer = new StreamWriter(
        new FileStream(outputPath, FileMode.Append, FileAccess.Write, FileShare.Read)))
    {
        string line;
        while ((line = await reader.ReadLineAsync()) != null)
        {
            await writer.WriteLineAsync(line);
        }
    }
}

• 如果确实需要逐次开关文件写入，可以在打开文件的逻辑中增加3-5次短间隔重试，遇到文件占用异常时等待20-50ms再尝试打开，避开系统进程占用的短窗口。

内容的提问来源于stack exchange，提问作者Mr._Rodman