C# 并没有像 Java Loom 那样在运行时内置一套完整的虚拟线程实现，但通过 async/await、自定义 TaskScheduler、单线程 SynchronizationContext 以及一些第三方纤程库，完全可以模拟出绿色线程的调度效果。绿色线程的核心特征是协作式切换：任务需要主动让出执行权，调度器才能切换到下一个任务。文件操作恰好是很容易破坏这套协作规则的环节，因为磁盘读写天然带有等待时间，如果等待发生在调度线程内部，其他纤程就只能排队。
要理解文件IO在虚拟线程或纤程模型中的表现，首先要区分两个层次：一是任务调度模型，二是IO完成模型。任务调度模型决定代码在哪个线程上执行、何时切换；IO完成模型决定发起读写后，内核如何通知完成。C# 的 async/await 默认使用线程池作为任务执行器，线程池线程在遇到异步IO时会释放回池中，等IO完成后再由线程池安排续体。这在视觉上很像绿色线程，但本质仍是操作系统线程的复用，并不是用户态纤程。
一、绿色线程和纤程在 .NET 中的实现口径
绿色线程通常指由用户态调度器管理的轻量执行单元，多个绿色线程可以运行在同一个操作系统线程上。它们的切换不依赖内核抢占，而是依赖代码主动让出，例如执行到某个 await 点、显式调用 yield 或者调度器的队列重新派发。.NET 标准库没有公开提供名为绿色线程的类，但开发人员可以通过单线程 SynchronizationContext、自定义 TaskScheduler 或基于迭代器的协程库构建出类似的运行形态。
在 Windows Forms 或 WPF 的 UI 线程模型中，所有异步回调都会排队回到创建控件的线程。这时 UI 线程就承担了类似纤程调度器的角色。假如在一个按钮点击事件里调用同步文件读取，例如 File.ReadAllText，整个 UI 队列都会被磁盘等待拖住，窗口表现为无响应。换成真正的异步文件读取，UI 线程只需要发出IO请求，随后立即返回消息循环，窗口可以继续处理其他交互。这个对比放到自定义纤程模型中也同样成立：调度线程不能被阻塞，否则所有纤程一起停顿。
二、同步文件IO与异步文件IO在底层调度上的差别
FileStream 的异步能力取决于文件句柄是否以异步方式打开。构造函数中有一个 useAsync 参数，或者可以通过 FileOptions.Asynchronous 指定。只有以异步句柄打开文件，ReadAsync 和 WriteAsync 才会走 IO 完成端口，操作系统在磁盘操作完成后，通过完成通知唤醒线程池。如果没有开启异步句柄，调用 ReadAsync 在 .NET Core 中很可能直接同步执行，然后返回一个已经完成的任务。虽然代码写的是 await，但线程根本没有让出。
下面这段代码展示了最常见的错误用法：
public byte[] ReadFileSync(string path)
{
using var fs = new FileStream(path, FileMode.Open, FileAccess.Read);
using var ms = new MemoryStream();
fs.CopyTo(ms);
return ms.ToArray();
}
这个方法无论放在线程池还是放在纤程调度器里，都会阻塞当前执行线程。对于普通线程池来说，损失尚可接受；但对于单线程纤程调度器来说，这就是全局停顿。再看正确用法：
public async Task<byte[]> ReadFileAsync(string path)
{
using var fs = new FileStream(
path,
FileMode.Open,
FileAccess.Read,
FileShare.Read,
4096,
FileOptions.Asynchronous);
using var ms = new MemoryStream();
await fs.CopyToAsync(ms);
return ms.ToArray();
}
FileStream 的构造参数里必须传入 FileOptions.Asynchronous，才能确保底层句柄使用重叠IO。重叠IO是 Windows 上的说法，在 Linux 上则是通过 io_uring 或线程池模拟，但对调用方来说效果一致：发起请求后线程可以离开，不用等待磁盘。
三、纤程模型下文件读写测试与表现
为了更直观地观察同步和异步文件操作对绿色线程模型的影响，可以用一个简单的单线程调度器来模拟。调度器维护一个工作队列，所有任务必须经过 await 才能让出执行权。下面是一个非常精简的实现：
public sealed class SingleThreadScheduler
{
private readonly ConcurrentQueue<Func<Task>> _work = new();
public void Post(Func<Task> work)
{
_work.Enqueue(work);
}
public async Task RunAsync()
{
while (_work.TryDequeue(out var work))
{
await work();
}
}
}
在测试中，先投递两个同步读取任务：每个任务都调用 File.ReadAllText 读取本地文件，然后等待调度器运行。由于第一个任务内部执行同步磁盘读取，调度线程从 work() 返回前会一直阻塞在 File.ReadAllText 上，第二个任务只有等第一个任务彻底完成后才能被取出。总耗时大致等于两个文件读取时间相加。
把文件读取改成真正的异步 FileStream，或者直接使用 .NET 6 及以上版本的 File.ReadAllTextAsync，情况会明显不同。第一个任务发起异步读取后，await 会把控制权交回调度器的循环，RunAsync 继续取出第二个任务并执行。两个任务的磁盘等待时间重叠，总耗时接近较慢的那个文件。需要注意的是，File.ReadAllTextAsync 在旧版 .NET Framework 中可能是用 Task.Run 包装的假异步，但在现代 .NET 中已经改为真实异步实现。判断依据仍然只有一个：底层文件句柄是否异步打开。
如果纤程调度器还要负责大量其他逻辑，这种阻塞差异会被进一步放大。一个同步文件读可能只慢几十毫秒，但在高并发服务里，几十毫秒足以让几百个纤程任务排队等待。反之，真正的异步文件IO虽然不能让磁盘变快，却能在等待期间把调度线程释放出来，让其他纤程继续推进。
四、避免文件操作拖垮绿色线程模型的实践建议
第一，所有文件读写都使用异步 API，并且在创建 FileStream 时明确传入 FileOptions.Asynchronous。不要使用同步的 File.ReadAllText、File.WriteAllText、File.Copy、File.Delete 等静态方法，除非能确定它们不会运行在纤程调度线程上。第二，对于第三方库封装的文件操作，不要只看方法名里带 Async 就认为它一定异步。可以通过测试在方法内部打印线程ID，观察调用前后线程是否发生变化，以及是否存在长时间阻塞。
第三，如果必须使用某个同步文件库或某段遗留代码，应该把它隔离到专用的线程池线程中执行。在纤程模型里可以使用 Task.Run 将同步文件操作丢给普通工作线程，再 await 回调度器。这虽然会消耗一个线程池线程，但至少保护了绿色线程调度循环。第四，在自定义 SynchronizationContext 或纤程调度器中，await 文件异步操作时要注意上下文捕获。如果每个续体都强制回到同一个纤程调度器，吞吐量可能受限于调度器本身。对于纯后台文件处理，可以在 await 时调用 ConfigureAwait(false)，避免不必要的上下文切换。
最后，文件路径本身也要尽量复用同一个 FileStream 实例，避免在高频调用中反复打开和关闭文件句柄。打开文件句柄也是有内核开销的，而且文件句柄的异步模式一旦确定就不能动态改变。把这些细节处理好，绿色线程模型下的文件IO完全可以做到高吞吐、低线程占用。核心原则只有一条：让磁盘等待发生在操作系统层，而不是发生在你的调度线程上。