embeddedfileprovider读不到文件的根本原因是资源未正确设为embeddedresource且命名空间或路径不匹配；需检查生成操作、logicalname、构造时前缀及subpath大小写，并用诊断代码验证资源名。
EmbeddedFileProvider 读不到文件？先确认资源是否真被嵌入
根本原因常出在编译设置上：EmbeddedFileProvider 只能访问标记为 EmbeddedResource 的文件，不是 Content 或 None。VS 里右键文件 → “属性” → “生成操作” 必须是 EmbeddedResource，且“复制到输出目录”必须是 不复制。
- 资源命名空间默认 = 项目默认命名空间 + 文件夹路径（如
MyApp.Assets.config.json在Assets/文件夹下，则完整资源名是MyApp.Assets.config.json） - 若手动改过
LogicalName（如在 .csproj 里加了<logicalname>data.json</logicalname>），就得按那个名字去查，不是文件名 - 用
dotnet build /bl生成 binlog，用 MSBuild Structured Log 查看CoreCompile阶段的EmbeddedFiles项，能直接看到最终嵌入的资源名
构造 EmbeddedFileProvider 时路径怎么写才对
EmbeddedFileProvider 构造函数第一个参数是 Assembly，第二个是资源所在根命名空间（可选）。它不认物理路径，只认资源名前缀 —— 这个前缀就是“查找起点”。
- 如果资源全在
MyApp.Static命名空间下（比如MyApp.Static.css\main.css），就传typeof(Program).Assembly和"MyApp.Static" - 传空字符串
""表示不限制前缀，但会暴露所有嵌入资源（含 System.* 等框架资源），不推荐 - 传错前缀（比如少一个层级）会导致
GetDirectoryContents返回空枚举，GetFileInfo返回Exists == false，但不会抛异常
读取文件内容时别直接用 ReadTextAsync —— 它不处理编码
IFileInfo.CreateReadStream() 返回的是原始字节流，没指定编码。如果资源是 UTF-8 无 BOM 的文本，直接用 StreamReader 默认会当 ANSI 解码，中文变乱码。
- 安全做法：用
fileInfo.CreateReadStream()→new StreamReader(stream, Encoding.UTF8) - 更省事：用
EmbeddedFileProvider自带的GetFileInfo(string subpath)拿到IFileInfo后，调fileInfo.Exists先判断，再读流 - 注意
subpath是相对于构造时传入的命名空间前缀的，比如前缀是"MyApp.Assets"，文件资源名是"MyApp.Assets.data.json"，那subpath就得写"data.json"，不能带前缀
调试时怎么快速验证资源名和内容
别靠猜。在代码里加一段临时诊断逻辑，比翻 .csproj 或 ILSpy 更快：
var provider = new EmbeddedFileProvider(typeof(Program).Assembly, "MyApp.Assets");
foreach (var item in provider.GetDirectoryContents(""))
{
if (item.IsDirectory)
Console.WriteLine($"DIR: {item.Name}");
else
Console.WriteLine($"FILE: {item.Name} (exists={item.Exists})");
}- 这段会列出所有匹配前缀的嵌入资源名（不含完整命名空间，只显示相对部分）
- 如果列表为空，说明前缀错了或资源根本没嵌入
- 如果能看到文件但
GetFileInfo("xxx")返回Exists == false，大概率是subpath大小写不一致（.NET Core 资源名区分大小写）
嵌入资源一旦编译进 DLL 就固定了，改名或删文件必须重新编译整个程序集；运行时没法 reload，这点容易忽略。
