CompositeFileProvider 是用于组合多个 IFileProvider 实例以统一访问的协调器，适用于需整合物理路径、嵌入资源和内存文件的场景；按添加顺序依次查找，同名文件仅返回首个匹配项。
CompositeFileProvider 是什么，什么时候该用它
它不是用来“打包文件”的工具，而是让多个 IFileProvider 实例像一个统一目录那样被访问的组合器。典型场景是：你有本地磁盘路径、嵌入资源、甚至内存中生成的文件，想统一用 IWebHostEnvironment.WebRootFileProvider 或 MVC 的视图查找逻辑去读取——这时才需要 CompositeFileProvider。
常见错误现象：GetDirectoryContents 返回空、GetFileInfo 找不到嵌入资源、静态文件中间件 404 却确定文件存在。
- 它不改变文件内容，也不做路径映射或重写
- 查找顺序严格按添加顺序：先查第一个 provider，没找到再查第二个，以此类推
- 如果多个 provider 都有同名文件（比如
logo.png），只会返回第一个匹配到的结果
怎么构造 CompositeFileProvider 并注入到 ASP.NET Core 服务中
核心是把多个 IFileProvider 实例传给 CompositeFileProvider 构造函数，然后替换掉默认的 WebRootFileProvider 或注册为自定义 service。
示例：合并 wwwroot + 嵌入资源 + 内存文件
var composite = new CompositeFileProvider(
new PhysicalFileProvider("wwwroot"),
new EmbeddedFileProvider(typeof(Program).Assembly, "MyApp.Resources"),
new MemoryFileProvider()
);
注入方式（.NET 6+）：
- 替换 WebRoot：在
Program.cs中调用builder.Services.AddSingleton<ifileprovider>(composite)</ifileprovider>，但注意这会影响整个IWebHostEnvironment.WebRootFileProvider - 单独注册：用
builder.Services.AddSingleton<ifileprovider>("MyComposite", sp => composite)</ifileprovider>，后续手动从 DI 获取 - 别直接替换
IHostingEnvironment或IWebHostEnvironment的ContentRootFileProvider，它通常不应被覆盖
嵌入资源路径和物理路径混用时的坑
EmbeddedFileProvider 的基路径必须和程序集内嵌资源的命名空间前缀完全匹配，否则 GetFileInfo("style.css") 会返回 Exists == false。
常见错误现象：嵌入资源明明存在，但 GetDirectoryContents("") 返回空枚举；或者路径带斜杠时行为异常。
- 确认资源是否标记为
EmbeddedResource（csproj 中<embeddedresource include="Resources\style.css"></embeddedresource>） -
EmbeddedFileProvider第二个参数是命名空间前缀，不是文件夹路径，比如资源实际路径是MyApp.Resources.style.css，就填"MyApp.Resources" - 物理路径要用正斜杠或反斜杠都行，但嵌入资源路径必须用正斜杠（
"css/app.css"），哪怕你在 Windows 上开发 -
CompositeFileProvider不会帮你做大小写归一化，Linux 下嵌入资源名大小写敏感，别依赖首字母大写自动匹配
MemoryFileProvider 和热更新配合的注意事项
它适合运行时动态提供文件（如 CMS 编辑后预览），但默认不支持监听变更，Watch 方法返回空 IChangeToken，所以不能用于触发视图重新编译或静态文件缓存刷新。
如果你需要“改了内存里的文件就立刻生效”，得自己实现带通知机制的 IFileProvider，或者绕过 CompositeFileProvider 单独处理。
-
MemoryFileProvider的文件内容是只读快照，修改字节数组不会自动同步到 provider - 往里面加新文件要用
WriteTextAsync或直接操作其内部Files字典（不推荐，线程不安全） - 和其他 provider 组合时，它的优先级由添加顺序决定——放太前面可能导致物理文件被“遮蔽”
最常被忽略的一点：CompositeFileProvider 本身不持有任何文件生命周期控制权，所有底层 provider 的释放（比如 PhysicalFileProvider 的文件句柄）仍需各自负责，别以为组合之后能自动 Dispose。
