Blazor应用部署到Azure需按模式选择服务：Server用App Service，独立WASM用Static Web Apps，托管式WASM则组合App Service与静态托管，并注意发布配置、日志诊断和HTTPS设置。
Blazor 应用部署到 Azure 主要看你用的是哪种模式：Blazor Server、Blazor WebAssembly（独立托管）还是带后端 API 的 WebAssembly（即“托管式”）。不同模式对应不同的 Azure 服务和操作路径，选错容易白忙活。
Blazor Server 应用 → 用 Azure App Service
这是最直接的方式。Blazor Server 是服务端渲染，依赖 .NET 运行时和 SignalR，必须跑在支持 ASP.NET Core 的环境里。
- 确保项目目标框架是 .NET 6+（推荐 .NET 8 或 .NET 9），Azure App Service 已原生支持
- 在 Azure 门户或 CLI 中创建 Linux 或 Windows 的 App Service，运行时选 ASP.NET Core X.X（如
aspnet:V9.0） - 发布时用
dotnet publish -c Release -o ./publish，再通过 ZIP 部署或 GitHub Actions 自动推送 - 注意配置
AllowedHosts（建议设为"*"或明确域名）、连接字符串、日志级别等应用设置
Blazor WebAssembly 独立版 → 用 Azure Static Web Apps
纯前端静态文件（HTML/JS/WASM），不需要服务器逻辑，适合用 Static Web Apps——免费、自动 CI/CD、自带 CDN 和 HTTPS。
- 代码必须托管在 GitHub（或 Azure DevOps），Static Web Apps 会监听 push 自动构建
- 构建命令填
dotnet build，输出位置填wwwroot（或你实际发布的静态目录，如bin/Release/net9.0/publish/wwwroot） - 如果调用外部 API，需在
wwwroot/appsettings.json中配好APIUrl；跨域问题由 Static Web Apps 的代理规则或后端 CORS 解决 - 无需管理服务器、扩缩容或打补丁，开箱即用
Blazor WebAssembly 托管版（含 Server 项目）→ 用 App Service + 静态托管组合
这种结构包含两个部分：客户端（WASM）和配套的 ASP.NET Core Hosted API。部署时要一起上，但方式不同。
- Server 项目照常部署到 App Service（作为后端 API）
- Client 项目生成的
wwwroot内容可一并打包进 Server 发布目录，或单独部署到 Static Web Apps - 关键点：Client 的
Program.cs中AddHttpClient必须指向已部署的 Server 地址（比如https://myapp.azurewebsites.net），不能留本地https://localhost:5001 - App Service 启动后，确保
web.config（Windows）或startup.sh（Linux）能正确服务静态文件和回退路由（/路由返回index.html）
进阶建议：别跳过这几步
无论哪种方式，这几个细节常被忽略，却直接影响上线成败：
-
检查发布配置：确认
dotnet publish输出的是完整可运行包（尤其 Server 模式下，别漏掉Microsoft.AspNetCore.Components.Web.dll等依赖） - 启用日志诊断：在 App Service 的“监控 > 日志”中打开应用日志和 Web 服务器日志，出错时第一眼看到异常堆栈
- HTTPS 强制跳转：在 App Service 的“自定义域”页勾选“HTTPS only”，避免混合内容警告
-
WASM 加载失败？ 检查浏览器控制台是否报 404（如
app.js或dotnet.wasm找不到），大概率是静态文件路径或 MIME 类型没配对
基本上就这些。选对服务、配对路径、看清日志，部署不复杂但容易忽略细节。
