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:5001App 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 类型没配对
基本上就这些。选对服务、配对路径、看清日志，部署不复杂但容易忽略细节。
