直接用System.IO写单元测试会失败，因其依赖磁盘、权限等外部状态，导致测试不可靠、慢、难并行且需手动清理残留文件；改用System.IO.Abstractions可解耦真实IO，通过IFileSystem接口注入内存实现，使测试可控、快速、隔离。
为什么直接用 System.IO 写单元测试会失败
因为真实文件 I/O 依赖磁盘、权限、路径存在性、并发写入等外部状态，导致测试不可靠、慢、难并行。比如 File.Exists("config.json") 在 CI 环境可能返回 false，不是逻辑错，而是环境缺文件；又比如 Directory.CreateDirectory 可能因权限失败，和被测逻辑无关。
更麻烦的是：测试后残留文件要手动清理，否则下次运行可能误读旧数据，try/finally 清理又让测试代码臃肿。
用 System.IO.Abstractions 替换真实 IO 的关键三步
它不替换 .NET 运行时，而是提供一套接口（如 IFileSystem）和可注入的实现，让你把文件操作“转嫁”给内存或模拟对象。
- 安装 NuGet 包：
System.IO.Abstractions（注意不是.Core或.TestHelpers，后者已废弃） - 修改被测类：所有文件操作必须通过构造函数接收
IFileSystem，而不是直接调用File/Directory静态方法 - 测试中传入
FileSystem实例（内存版）：var fileSystem = new FileSystem();—— 它默认就是纯内存实现，无需额外配置
示例改造：
// 改造前（不可测）
public class ConfigLoader
{
public string ReadConfig() => File.ReadAllText("config.json");
}
// 改造后（可测）
public class ConfigLoader
{
private readonly IFileSystem _fileSystem;
public ConfigLoader(IFileSystem fileSystem) => _fileSystem = fileSystem;
public string ReadConfig() => _fileSystem.File.ReadAllText("config.json");
}
FileSystem 实例在测试中怎么初始化和预置数据
FileSystem 构造即内存空实例，但你得主动写入测试所需文件，否则 ReadAllText 仍会抛 FileNotFoundException。
- 用
_fileSystem.File.WriteAllText("a.txt", "hello")写入字符串 - 用
_fileSystem.Directory.CreateDirectory("logs")创建目录（即使父目录不存在，它也会自动补全） - 路径分隔符统一用正斜杠
/或Path.Combine，避免 Windows/Linux 差异；FileSystem内部会自动归一化 - 注意：内存文件系统不支持硬链接、ACL、只读属性等真实特性，若业务强依赖这些，需另作适配或跳过该路径测试
常见错误：忘记写入文件就调用读取，报错信息是 System.IO.FileNotFoundException，但堆栈指向你的业务代码，容易误判为逻辑问题。
测试边界场景时，FileSystem 怎么模拟异常
内存版 FileSystem 默认不会抛异常（比如删不存在的文件只是静默），但你可以用 FileSystemProxy 包装它，再重写特定行为。
- 想让某次
Delete失败？继承FileSystemProxy，重写DeleteFile方法，在特定路径 throw - 更轻量做法：用 Moq 模拟
IFileSystem接口，对单个方法设定期望，例如mock.Setup(x => x.File.Exists("x")).Returns(false) - 注意：Moq 不能 mock
static成员，所以必须确保所有 IO 调用都走接口实例，不能混用File.Exists和_fs.File.Exists
真实项目里最容易漏掉的是“文件被其他进程占用”这类异常，内存系统无法原生模拟，需要靠 Moq 手动注入 IOException 来覆盖。
真正难的不是接入 System.IO.Abstractions，而是把现有代码里所有隐式文件访问点都找出来——尤其是日志组件、配置加载器、第三方 SDK 内部的静态调用。这些地方不改，测试就永远有漏网之鱼。
