Windows 文件系统不提供IO公平性保障，FileStream等API不感知公平性，I/O调度由NTFS/ReFS驱动和存储栈按优先级与队列深度处理，而非按进程或用户配额分配带宽。
Windows 文件系统本身不提供 IO 公平性保障
直接说结论：FileStream、File.ReadBytes、Directory.GetFiles 这些 API 完全不感知“公平性”——它们只是把请求扔给 NTFS / ReFS 驱动和存储栈，而 Windows 内核的 I/O 调度器（如默认的 NTFS + storport）按优先级+队列深度调度，不是按线程/用户/进程配额分配带宽。
这意味着：一个后台压缩任务用 FileStream 拼命写大文件，会显著拖慢前台 UI 线程读取配置文件的速度，且 .NET 层面毫无干预能力。
C# 层唯一可控的公平性入口是异步 I/O + 限流
真正能动手的地方在应用层：用 async/await 把阻塞拆开，再套一层资源约束。关键不是“让系统变公平”，而是“不让某个任务吃光所有 I/O 吞吐”。
-
Task.Run包裹同步 I/O 是反模式——它只转移了线程饥饿，没缓解磁盘争抢 - 必须用
FileStream.ReadAsync/WriteAsync，底层走的是真正的 overlapped I/O，才能被系统线程池复用 - 配合
SemaphoreSlim控制并发数（例如限制最多 3 个并发写入），比用ThreadPool.SetMaxThreads有效得多 - 注意
SemaphoreSlim的WaitAsync要超时，否则某个卡死的 I/O 可能让后续所有请求永久挂起
示例：限制同时最多 2 个文件写入
var semaphore = new SemaphoreSlim(2, 2);
await semaphore.WaitAsync(TimeSpan.FromSeconds(30));
try
{
await using var fs = new FileStream(path, FileMode.Create, FileAccess.Write, FileShare.None, 4096, useAsync: true);
await fs.WriteAsync(buffer, CancellationToken.None);
}
finally
{
semaphore.Release();
}多用户场景下，权限隔离 ≠ IO 隔离
Windows 用户账户控制（UAC）、Identity、WindowsIdentity 能隔离文件访问权限，但完全不影响物理磁盘排队行为。两个不同用户的进程，只要都往同一块 SSD 写数据，照样互相干扰。
-
LogonUser或WindowsIdentity.RunImpersonated不改变 I/O 调度优先级 - 服务进程（如
LocalSystem）默认有更高线程优先级，可能无意中抢占前台用户 I/O 时间片 - 真要分用户限速，得靠外部工具：比如用 Windows QoS 策略（
netsh interface qos）限制某进程带宽，或通过 WMI 查询Win32_PerfFormattedData_PerfDisk_PhysicalDisk做自适应降频
SSD 和 HDD 对“公平性”的反应完全不同
机械硬盘（HDD）时代，I/O 公平性问题更明显——寻道时间长，单个大请求就能让队列后面所有请求等上百毫秒。而现代 NVMe SSD 延迟低、并行深，表面看“公平”了，实则掩盖了更隐蔽的问题：
- SSD 的写放大和垃圾回收（GC）会让某些写入突然卡住 100ms+，这种延迟不可预测，也无从限流
-
FileOptions.SequentialScan在 HDD 上有效，在 NVMe 上基本无效，甚至可能降低性能 - 用
FILE_FLAG_NO_BUFFERING（对应FileOptions.NoBuffering）绕过系统缓存，看似“更底层”，实则要求对齐、禁用缓存后反而更容易触发 SSD 内部 GC 尖峰
所以别迷信“更底层就更可控”——越靠近硬件，越要接受它的脾气。
真正难的从来不是写几个 async 方法，而是判断哪类 I/O 必须保响应（如 UI 配置读取），哪类可以压队列（如日志归档），以及当 SSD 开始 GC 抖动时，你的限流逻辑是否还成立。
