静态文件404主因是中间件顺序错误或ContentTypeProvider缺失：UseStaticFiles()必须在UseRouting()之后、UseEndpoints()之前；新文件类型（如.webp）需手动注册ContentTypeProvider。
静态文件 404？不是路径写错了，是中间件没走到、没配对、或根本没认出文件类型。
UseStaticFiles() 必须在 UseRouting() 之后
中间件顺序错，UseStaticFiles() 就彻底失效——它不调用 next，位置靠前等于被路由系统直接吞掉。
-
UseStaticFiles()必须放在UseRouting()之后、UseEndpoints()或MapControllers()之前 - 常见错误：把它写在
UseRouting()前面，结果所有/css/app.css请求都被路由中间件判为“无匹配端点”，直接返回 404 - Kestrel 本身不处理静态文件，全靠这个中间件；IIS 或 Linux 部署时别指望它“自动生效”
要访问 wwwroot 以外的目录，必须显式配置 FileProvider
默认只服务 wwwroot，把图片扔进 uploads/ 或 client-dist/ 目录，不配 FileProvider 就永远 404。
-
FileProvider必须是绝对路径，推荐用Path.Combine(env.ContentRootPath, "uploads")拼接 -
RequestPath是 URL 前缀（如"/uploads"），必须以/开头，和磁盘结构无关 - 多个
UseStaticFiles()调用允许，但注意顺序：先注册的规则先匹配，后注册的不会 fallback - Linux 上大小写敏感，
logo.PNG和logo.png是两个文件，PhysicalFileProvider不做转换
WebP、WOFF2 等新格式返回空 Content-Type？补 ContentTypeProvider
浏览器或 CDN 拒绝加载图片/字体，很可能不是 404，而是响应头里 Content-Type 为空——FileExtensionContentTypeProvider 默认不认识这些扩展名。
- 创建
FileExtensionContentTypeProvider实例，用TryAdd注册新映射 - 例如：
provider.TryAdd(".webp", "image/webp")、provider.TryAdd(".woff2", "font/woff2") - 把配置好的 provider 赋给
StaticFileOptions.ContentTypeProvider - 别漏掉
new StaticFileOptions { ContentTypeProvider = provider }这个整体传入
发布后静态文件丢失？检查 wwwroot 是否被正确包含
开发时能跑，发布后 404，大概率是 wwwroot 文件夹没打进输出目录。
- 在 .csproj 中确认
wwwroot下的文件Build Action是Content，且Copy to Output Directory是PreserveNewest或Always - 发布后检查输出目录（如
bin/Release/net8.0/publish/wwwroot/）是否存在对应文件 - 自定义目录（如
public/）同理：确保物理目录存在、应用有读取权限，尤其在 Linux 容器或 IIS 应用池下
最容易被忽略的是中间件顺序和 ContentTypeProvider 的缺失——前者让请求根本到不了静态文件逻辑，后者让文件虽返回却无法被浏览器识别。这两处一错，现象都是“找不到”，但根因完全不同。
