IFileProvider 是统一抽象不同文件源的接口，非单次读取快捷方式；需检查 Exists 再调用 CreateReadStream，路径用 Unix 风格，不解析 ..，大小写敏感依系统而定，映射子目录应校验路径合法性，避免内存泄漏需注意生命周期管理。
为什么 IFileProvider 不是“读文件的快捷方式”
它根本不是为单次读取设计的——而是为统一抽象不同来源的文件系统（物理磁盘、嵌入资源、内存、甚至远程 ZIP）提供的接口。直接用 GetFileInfo 去读一个不存在的路径，不会抛异常，而是返回一个 IFileInfo 实例，其 Exists 为 false；你得自己检查，否则后续调用 CreateReadStream() 会崩在 NullReferenceException 上。
常见错误现象：Object reference not set to an instance of an object 出现在 fileInfo.CreateReadStream() 后，其实只是因为忘了先判 fileInfo.Exists。
- 所有路径传入都按 Unix 风格处理（
/分隔），即使在 Windows 上也别写\ -
IFileProvider不解析..，路径越界（如../web.config）会被静默截断或返回不存在，不报错也不警告 - 物理提供者（
PhysicalFileProvider）对大小写敏感与否，取决于底层 OS 和文件系统，Linux 下真会找不到Index.html如果你写了index.html
PhysicalFileProvider 怎么安全地映射到子目录
直接 new PhysicalFileProvider(@"C:myappwwwroot") 是最常见写法，但它会让整个目录对外“可见”。如果路径拼接没做白名单校验，攻击者可能通过构造路径（如 ../../web.config）绕过限制。
正确做法是用 PhysicalFileProvider 的构造函数第二个参数：一个 ExclusionFilters 或更稳妥的——用 CompositeFileProvider + 路径前缀约束。
- 永远不要把用户输入直接拼进
GetFileInfo(path)，先用Path.GetRelativePath(root, userPath)校验是否仍在合法子树内 - 推荐初始化时就限定根目录，并用
NormalizePath统一处理：var root = Path.GetFullPath(@"C:myappwwwroot"); -
PhysicalFileProvider默认监听文件变化（FileSystemWatcher），高并发小文件场景下可能触发大量事件，导致 CPU 毛刺；如不需要热更新，可传new PhysicalFileProviderOptions { WatchForChanges = false }
嵌入资源怎么用 ManifestEmbeddedFileProvider
核心限制：只认程序集里标记为 EmbeddedResource 的文件，且路径必须和程序集清单里的完全一致（含默认命名空间）。比如类库项目中有个 Assets/logo.png，实际嵌入 ID 很可能是 MyLib.Assets.logo.png。
常见错误现象：GetFileInfo("logo.png") 返回 Exists == false，但 GetDirectoryContents("") 却列不出任何东西——大概率是嵌入 ID 对不上，或没在 .csproj 里正确声明：
<ItemGroup> <EmbeddedResource Include="Assets**" /> </ItemGroup>
- 调试技巧：用
assembly.GetManifestResourceNames()打印所有嵌入名，确认路径格式 -
ManifestEmbeddedFileProvider不支持写操作，所有CreateReadStream()返回的是只读流，且不能 seek（CanSeek == false） - 如果资源在主程序集（
Assembly.GetExecutingAssembly()），注意发布后可能被裁剪（Trimming），需在.csproj中加<trimmerrootassembly include="MyApp"></trimmerrootassembly>
IFileProvider 在中间件里怎么避免内存泄漏
很多人把 IFileProvider 实例缓存在静态字段或单例服务里，却忽略了 PhysicalFileProvider 内部持有 FileSystemWatcher，而后者会强引用回调委托——如果委托捕获了控制器实例或 HttpContext，整个请求上下文就无法释放。
性能影响比想象中严重：每个 PhysicalFileProvider 实例对应一个独立的 watcher 线程+内核句柄，Windows 上句柄数有限，开太多会直接 IOException。
- 除非明确需要跨请求共享（比如全局静态资源），否则优先用 Scoped 或 Transient 生命周期注册
IFileProvider - 若必须单例，请确保构造时不捕获任何请求作用域对象；尤其避免在 lambda 里用
context.RequestServices.GetService<ifileprovider>()</ifileprovider> - 测试时用
dotnet-counters monitor -p <pid> --counters Microsoft.AspNetCore.Hosting</pid>观察file-watcher-count是否持续上涨
最麻烦的其实是路径语义——IFileProvider 把“路径”当成纯字符串匹配，不走 OS 层解析。这意味着 NormalizePath、大小写、斜杠方向、空格编码这些细节，全得你自己对齐，框架不会帮你兜底。
