为何微软官方教程需将同一dotnet core应用分两次推送作为前后端？

结论先行 #

你完全不需要按照教程的部署方式实现需求，教程的冗余部署仅为简化演示流程、降低新手入门的配置复杂度，不属于生产环境的最佳实践。

你提出的拆分部署方案完全可行 #

你提到的「API部署到Azure App Service、静态资源部署到静态托管服务」的方案是完全支持的，且是更推荐的生产级部署方式：

• .NET Core API侧：单独部署到Azure App Service，仅保留后端接口逻辑，不需要托管任何前端静态资源，给该服务单独配置Azure AD作为身份验证提供方，开启JWT令牌校验即可。
• 前端静态资源侧：可以直接部署到Azure静态Web Apps，该服务原生支持集成Azure AD身份验证，配置完成后前端可以直接拿到合法的访问令牌，只需要在API的Azure AD配置中给前端的客户端ID授予对应接口的访问权限，就能正常完成接口调用。

拆分部署的优势 #

完全符合你对成本和架构合理性的判断：

• 成本层面：Azure静态Web Apps有免费使用配额，即使选用付费规格也远低于单独运行一个App Service的成本，相比教程的双App Service部署方案至少节省一半的基础资源开支。
• 架构层面：前后端完全解耦，支持独立迭代、独立部署，前端静态资源还可默认享受到CDN加速降低访问延迟，API侧也可以单独配置扩缩容、限流、日志监控等策略，互不干扰。

仅需额外补充一处配置 #

拆分后只需要在API的App Service配置中添加CORS规则，放行你前端静态服务的访问域名，其余的身份验证逻辑和你在教程中接触到的逻辑完全一致，不需要修改核心代码。

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