.net8 http请求图片路径不加wwwroot 可以正常打开，就是m3u8文件需要加wwwroot 才能访问

图片能正常访问，而 .m3u8 文件需要加上 /wwwroot 才能访问，这个现象很关键。它指向的问题不再是简单的MIME类型缺失，而很可能是应用的路由规则对 .m3u8 这类特殊扩展名产生了干扰。

🎯 核心原因：路由 "劫持" 了你的 .m3u8 请求

在 ASP.NET Core 中，请求的处理流程是：URL (不带 /wwwroot) -> 路由系统 -> 静态文件中间件。

• 图片请求 (/images/pic.jpg)：路由系统识别出 .jpg 是静态文件扩展名，直接跳过路由处理，请求被静态文件中间件正常响应-。

• .m3u8请求 (/videos/index.m3u8)：因为 .m3u8 不在系统默认的静态文件扩展名列表中，路由系统认为这是一个动态请求，会尝试匹配一个名为 /videos/index.m3u8 的 Controller 或 Action。找不到，就返回 404。

• • 带 /wwwroot的请求 (/wwwroot/videos/index.m3u8)：这个 URL 因为包含 /wwwroot，很可能绕过了你的应用路由，直接被 IIS 或 Kestrel 当作物理文件路径处理，从而找到了文件。

  🧐 关键证据：为什么 MIME 类型配置会 "失效"？

  这正是问题的迷惑之处：当请求被路由 "劫持"时，它根本没进入静态文件处理环节，因此你配置的 ContentTypeProvider 也就没机会生效。

  🛠️ 解决方案：让路由系统 "放过" .m3u8 文件

  既然知道了原因，我们可以从两个方面来解决这个问题。

方案一：将 .m3u8 纳入已知静态文件类型（推荐）

这是最直接、最安全的方法，从根源上解决问题，避免路由干扰。在你的 Program.cs 文件中修改 UseStaticFiles 配置：

using Microsoft.AspNetCore.StaticFiles;

// ... 其他代码 ...

var app = builder.Build();

// ... 其他中间件 ...

// 1. 创建自定义 ContentTypeProvider
var provider = new FileExtensionContentTypeProvider();
// 2. 添加 .m3u8 文件的 MIME 映射
provider.Mappings[".m3u8"] = "application/vnd.apple.mpegurl";
// 3. (可选但建议) 添加 .ts 文件的 MIME 映射
provider.Mappings[".ts"] = "video/mp2t";

// 4. 将自定义的 Provider 配置到静态文件中间件
app.UseStaticFiles(new StaticFileOptions
{
    ContentTypeProvider = provider
});

// ... 后续代码如 app.UseRouting(), app.MapControllers() 等 ...

UseStaticFiles 中间件会识别 ContentTypeProvider 里的映射，将 .m3u8 标记为静态文件，请求会由它直接处理，从而避免被路由系统“劫持”