ASP.NET Core 9.0 MapStaticAssets在负载均衡环境的集成问询

我现有一个基于ASP.NET Core 8.0构建的应用，计划升级至.NET 9，并打算采用新的MapStaticAssets特性实现构建时压缩与优化。

系统运行于Docker容器中，部署在无粘性会话的负载均衡器后方，实例数量会随流量动态增减。

当前系统的静态文件处理方案：

• 通过静态文件中间件（搭配压缩与缓存标头）在本地实例托管静态文件，同时将构建版本加入所有静态文件名中
• 构建过程中，将所有文件副本上传至AWS S3
• 每个实例包含回退逻辑：若本地不存在请求的静态文件，则从AWS S3获取
• 该方案保证新版本部署期间，旧实例仍能提供新静态文件

但使用MapStaticAssets后，原有方案变得复杂：应用引用~/css/site-1.0.0.css时，HTML实际会请求/css/site-1.0.0.[hash].css，服务器会根据压缩类型返回/wwwroot/css/site-1.0.0.css.br或/wwwroot/css/site-1.0.0.css.gz，并附带正确标头。

目前我有两个可选方案：

1. 实现「粘性会话」，确保页面/视图请求的静态文件来自同一实例（我倾向于不采用此方案）
2. 构建完成后读取生成的[Project Name].staticwebassets.endpoints.json文件，上传原始静态文件并将其重命名为带哈希的路由名称（例如将/css/site-1.0.0.css重命名为带哈希的文件名）

方案2可行，但我担忧[Project Name].staticwebassets.endpoints.json属于未充分文档化的特性，过度依赖.NET实现细节可能在未来版本因微软变更而引发问题。

简言之，我的问题是：新的MapStaticAssets特性是否具备我未发现的内置能力，可实现与中央文件存储的集成，以支持多实例集群环境？

注：生产环境中还存在CDN部署的复杂情况，但我认为这不会影响问题本身。

.NET 9的MapStaticAssets特性没有内置的中央文件存储集成能力，它的核心设计聚焦于构建时静态资源的压缩、哈希重写和运行时的请求映射，并未提供与S3这类外部存储直接对接的功能。

针对你的场景，给出以下建议：

• 方案2的替代优化：使用官方文档化的API而非直接解析JSON文件
  如果你想避免直接依赖未公开的staticwebassets.endpoints.json，可以在构建阶段使用.NET的Microsoft.AspNetCore.Mvc.TagHelpers相关API，或者通过MSBuild任务来获取静态资源的哈希映射关系。比如，利用StaticWebAssetsManifest相关类型（虽属于Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation包，但相对更稳定）读取资源映射，而非直接操作JSON文件。
• 将静态资源完全托管到S3+CDN
  既然你已经在使用S3，考虑在构建完成后直接将处理好的带哈希的静态资源（包括压缩后的.br/.gz文件）上传到S3，并配置CDN指向S3。然后修改应用的静态资源引用直接指向CDN地址，而非通过应用实例托管。这种方式彻底绕过了实例间的资源同步问题，也完全适配MapStaticAssets的哈希重写逻辑——只需要确保TagHelper生成的资源URL是CDN的地址即可。
• 保持回退逻辑，但适配MapStaticAssets的哈希格式
  如果必须保留实例本地托管+S3回退的模式，可以在构建阶段将压缩后的静态文件（带哈希的路由对应文件）同步到S3，而非原始文件。比如，构建生成/css/site-1.0.0.[hash].css对应的压缩文件后，直接上传这些文件到S3的对应路径，这样旧实例在找不到本地哈希文件时，可以直接从S3获取对应的压缩文件，无需额外重命名。

需要注意的是，staticwebassets.endpoints.json的格式在.NET 9中是稳定的，但微软确实没有将其列为公开的长期支持API，未来版本存在变更风险。因此，优先选择基于公开API或完全托管到外部存储的方案会更可靠。

内容的提问来源于stack exchange，提问作者user2124521