System.IO.Abstractions 能不能解决多路径虚拟化
不能直接解决，它只是
System.IO的抽象封装，不提供路径合并或视图叠加能力。你用它换掉
File、
Directory调用，只是方便测试和解耦，底层仍是单路径操作。
真正需要的是“文件系统层的逻辑聚合”，不是接口抽象。常见误判是以为换掉
System.IO就能自动支持多源读取——其实连
Directory.EnumerateFiles("C:\src;D:\alt") 这种写法都会直接抛 ArgumentException。 它不改变 Windows 或 .NET 对“路径是单一字符串”的根本假设 所有
IFileSystem实现（比如
FakeFileSystem）仍要求每个操作指向一个确定物理位置 若强行在
GetDirectories()里拼接多个目录结果，会丢失父子关系、无法处理相对路径跳转（如
..）、也无法响应
FileSystemWatcher
用自定义 FileSystemProvider 搭配 VirtualPathProvider 行不行
在 ASP.NET Framework 里
VirtualPathProvider可以拦截
~/Views/xxx.cshtml这类请求，但它只对 Web 环境生效，且仅限于
HttpContext.Current下的资源加载；.NET Core / .NET 5+ 已彻底移除该机制，也没有等效替代。
换句话说：这不是通用文件系统方案，而是 ASP.NET 特定的视图/资源查找钩子，不能用于
File.ReadAllText("config.json") 或 Assembly.LoadFrom()这类任意 IO 场景。
VirtualPathProvider不影响
System.IO.File、
FileStream、
Path等任何基础 API 它不提供
DirectoryInfo或
DriveInfo的虚拟化支持 无法处理命令行工具、配置文件加载器、序列化框架等绕过 Web 上下文的调用
最简可行：用 IFileSystem + 自定义枚举器模拟虚拟视图
如果你只需要“读取时合并多个目录内容”，不涉及写入、监听、权限控制或符号链接解析，可以用一个轻量包装层实现逻辑视图。核心是把多个物理路径当成“只读挂载点”，统一暴露为
IEnumerable<fileinfo></fileinfo>和
IEnumerable<directoryinfo></directoryinfo>。
示例思路：
public class MergedFileSystem
{
private readonly string[] _roots;
public MergedFileSystem(params string[] roots) => _roots = roots;
public IEnumerable<FileInfo> EnumerateFiles(string pattern = "*.*")
{
return _roots
.Where(Directory.Exists)
.SelectMany(root => Directory.EnumerateFiles(root, pattern, SearchOption.AllDirectories))
.Distinct() // 防止同名文件重复
.Select(path => new FileInfo(path));
}
}
必须手动处理路径冲突：两个根目录下都有 /lib/log.dll，你得决定用哪个（按顺序优先？校验哈希？抛异常？）
SearchOption.AllDirectories在深层嵌套时性能明显下降，建议加缓存或限制层级 返回的
FileInfo的
FullName仍是物理路径，无法伪造“统一前缀”（如全显示为
/virtual/lib/...），否则会破坏
File.OpenRead()等调用 不支持
File.Move()、
Directory.Create()等写操作——虚拟视图默认只读
.NET 6+ 中 FileSystemWatcher 怎么适配多路径
原生
FileSystemWatcher不支持监控多个根路径，每次只能绑定一个
Path。强行轮询多个实例会导致事件乱序、重复触发、内存泄漏（未正确
Dispose）。
可靠做法是：启动 N 个独立
FileSystemWatcher，用同一个
SynchronizationContext或
Channel<filesystemeventargs></filesystemeventargs>统一派发事件，并在消费端做路径归一化（例如把
C: ile.txt和
D: ile.txt映射到
/merged/file.txt）。 每个 watcher 必须设置
IncludeSubdirectories = true，否则子目录变更不会上报 避免在
Changed回调里直接处理耗时逻辑（如重新加载配置），容易阻塞线程池 Windows 下长路径（>260 字符）需启用
\?前缀并开启组策略，否则 watcher 会静默失败 Linux/macOS 上 inotify 有 fd 数量限制，大量 watcher 容易触发
Too many open files事情说清了就结束。真正的难点不在“怎么列文件”，而在“怎么让所有现有代码无感使用这个虚拟路径”——只要还依赖
string类型的路径参数，就绕不开物理路径泄露和语义歧义。
