C# 文件系统延迟注入 C#在测试中如何模拟慢速磁盘或网络文件系统

task.delay不能替代真实i/o延迟，因其不占用线程、不触发设备行为，无法暴露线程饥饿、死锁或iocp积压等问题；真实延迟需在FileStream构造、read/write等p/invoke调用处模拟，并区分同步/异步路径与运行环境。

为什么 Task.Delay 不能直接替换真实 I/O 延迟

因为真实文件操作（比如 File.ReadAllText）是同步阻塞的，而 Task.Delay 是纯异步空转——它不占用线程，也不触发任何底层设备行为。测试中如果只用 Task.Delay 模拟“慢磁盘”，会掩盖线程饥饿、同步上下文死锁、或 FileStream 内部缓冲区竞争等问题。

真正需要模拟的是：调用方感知到延迟 + 底层系统资源被真实占用（如线程池线程卡住、句柄未释放、IOCP 队列积压）。所以得从 I/O 入口处拦截，而不是在业务逻辑里插个延时。

• 别在业务方法里写 await Task.Delay(2000) 再调 File.Read——这测不出同步 API 的阻塞影响
• 别用 Thread.Sleep 替代——它会无差别冻结当前线程，无法区分 CPU-bound 和 IO-bound 场景
• 真实延迟要体现在 FileStream 构造、Read、Write 或 Directory.GetFiles 等实际 P/Invoke 调用之后

用 FileSystemProvider + 接口抽象做可注入延迟

.NET 6+ 的 IFileSystem（来自 microsoft.Extensions.FileProviders）本身不支持延迟，但你可以封装一层。关键是把所有文件操作收归到一个接口，比如：

public interface IFileAccessor {     string ReadAllText(string path);     Task<string> ReadAllTextAsync(string path);     void WriteAllText(string path, string content);     Task WriteAllTextAsync(string path, string content); }

然后实现两个版本：一个是直通 File 类的真实版；另一个是带延迟的测试版，内部用 Task.Delay + File 组合，且延迟时机要贴近真实路径：

• 对同步方法，先 Task.Delay 再执行 File.ReadAllText——模拟“打开慢、读取慢”
• 对异步方法，用 await Task.Delay + await File.ReadAllTextAsync——保持 async/await 链完整
• 延迟值建议按操作类型分档：Open 延 100–500ms，Read 延 50–200ms/MB，避免固定 2s 导致测试失真

绕不过去的坑：FileStream 构造本身就会触发同步 I/O

即使你封装了 IFileAccessor，如果测试代码里还直接 new FileStream(path, ...)，延迟逻辑就彻底失效。很多库（比如 ImageSharp、XmlReader）内部也会偷偷 new FileStream。

这时必须用更底层的拦截手段：

• 用 AssemblyLoadContext + IL 编织（如 Fody）重写 FileStream 构造函数调用——太重，仅限集成测试
• 改用内存映射文件（MemoryMappedFile）配合自定义 Stream 子类，在 Read 里插入延迟——适合单元测试，但不模拟磁盘寻道
• 最实用的折中：在测试启动时，把 AppContext.SetSwitch("System.IO.UseNet5CompatFileStream", true) 关掉，强制走新 FileStream 实现（它更易被 mock），再配合 Moq 对 Stream 抽象进行延迟注入

别忽略网络文件系统（SMB/NFS）特有的超时表现

本地磁盘延迟是“慢但稳定”，而 SMB 挂载点可能突然返回 IOException：“The specified network name is no longer available”，或者卡住 30 秒后才抛 TimeoutException。单纯加 Task.Delay 模拟不了这种非对称失败。

测试这类场景，必须组合以下行为：

• 前几次读写成功，第 N 次随机抛 IOException（模拟连接断开）
• 用 CancellationTokenSource.CancelAfter(15_000) 包裹调用，验证你的代码是否响应取消
• 检查是否用了 FileOptions.Asynchronous——没设这个，ReadAsync 在 SMB 上仍可能退化为同步调用

最麻烦的一点是：windows 和 linux 下 SMB 超时策略完全不同，Wsl2 里的挂载点行为又和原生 Linux 不一致。所以延迟注入必须绑定具体运行环境，不能靠一套配置打天下。