IFileProvider 是 ASP.NET Core 中解耦物理路径依赖的核心接口，支持从磁盘、嵌入资源、ZIP、数据库等统一读取静态文件，避免硬编码路径导致跨平台失败。
什么是 IFileProvider，它能解决什么问题
IFileProvider 是 ASP.NET Core 中用于抽象文件访问的核心接口，不是为“虚拟磁盘”或“内存文件系统”而生的通用工具，而是为了解耦物理路径依赖——比如你希望从嵌入资源、程序集、ZIP 包、数据库甚至远程 HTTP 服务读取静态文件（如 wwwroot 下的 JS/CSS），又不想硬编码 File.ReadAllText("path/to/file.js") 这种会崩在 Linux 或容器里的写法。
它不替代 System.IO，而是提供统一入口：只要实现 IFileProvider，就能被 WebHostBuilder.UseWebRoot()、StaticFileMiddleware、Razor 视图引擎等原生组件识别和使用。
如何用 PhysicalFileProvider 和 EmbeddedFileProvider 做混合文件源
这是最常见且实用的组合：主静态资源走磁盘，第三方库的默认样式/脚本走嵌入资源。
-
PhysicalFileProvider必须传入一个绝对路径，相对路径（如"wwwroot"）会被解释为相对于当前工作目录（Environment.CurrentDirectory），而该目录在 IIS、Linux systemd、dotnet watch 下各不相同，极易出错 -
EmbeddedFileProvider需要指定程序集 + 资源前缀，资源名必须是编译后的真实名称（查看.csproj中<embeddedresource></embeddedresource>的LogicalName，或用assembly.GetManifestResourceNames()调试确认） - 多个
IFileProvider不能直接合并，需用CompositeFileProvider组装，且顺序重要：前面的 provider 先匹配，匹配成功就不再往后查
var physical = new PhysicalFileProvider(Path.GetFullPath("wwwroot"));
var embedded = new EmbeddedFileProvider(typeof(Program).Assembly, "MyLib.Assets");
var composite = new CompositeFileProvider(physical, embedded);
services.AddSingleton<IFileProvider>(composite);
注意：CompositeFileProvider 不支持写入，所有 provider 都只读。
IFileInfo 的 Exists 和 PhysicalPath 容易误用
IFileInfo.Exists 是唯一可靠的“文件是否存在”判断方式，别用 fileInfo.PhysicalPath != null && File.Exists(fileInfo.PhysicalPath) —— 对嵌入资源或自定义 provider，PhysicalPath 就是 null，强行访问会 NRE。
-
PhysicalPath仅对PhysicalFileProvider有效，其他 provider 返回null -
Exists == false不代表路径非法，可能是权限不足、provider 未覆盖该路径，或大小写敏感（Linux 下"Style.css"≠"style.css"） -
LoadFileContent()（非标准方法）不存在，正确读取方式是打开Stream：using var stream = fileInfo.CreateReadStream(); using var reader = new StreamReader(stream); string content = await reader.ReadToEndAsync();
自定义 IFileProvider 时最容易漏掉的两个点
写一个从数据库或 S3 加载文件的 provider 很简单，但上线后常因以下两点失败：
- 忘记重写
GetDirectoryContents(string subpath)：即使你只打算按需读单个文件，ASP.NET Core 的静态文件中间件、Razor 编译器仍会调用它来扫描目录结构。返回空IDirectoryContents（如new NotFoundDirectoryContents()）可避免 500 错误，但若要支持目录列表（如index.html自动 fallback），就得真实实现 -
IFileInfo.LastModified设为DateTimeOffset.MinValue会导致浏览器缓存失效或 ETag 计算异常；建议设为数据记录的更新时间，或至少用DateTimeOffset.UtcNow（虽不精确，但比默认值安全）
虚拟文件系统的复杂性不在接口本身，而在你如何让 Exists、LastModified、CreateReadStream() 这三者的行为，在不同 provider 间保持语义一致。
