blazor容器化部署需区分webassembly与server模式：前者为静态文件，用nginx镜像托管；后者依赖.net运行时和signalr，需asp.net core托管镜像，并配置websocket升级头及环境变量。
Blazor 应用容器化部署，核心是把编译后的静态文件（Blazor WebAssembly）或托管服务（Blazor Server）打包进 Docker 镜像，再通过容器运行。关键区别在于：WebAssembly 是纯前端，适合 Nginx/Apache 静态托管；Server 模式依赖 .NET 运行时和 SignalR，需完整 ASP.NET Core 托管环境。
Blazor WebAssembly 容器化（推荐轻量部署）
它本质是个静态网站，构建后输出 wwwroot 下的 HTML/JS/WASM 文件，无需 .NET 运行时。
- 用
dotnet publish -c Release生成发布文件（默认在bin/Release/netX.X/publish/wwwroot） - 基于
nginx:alpine或mcr.microsoft.com/dotnet/aspnet:8.0-alpine（带 nginx 的精简版）构建镜像 - 在 Dockerfile 中把发布文件复制到
/usr/share/nginx/html，并可选覆盖nginx.conf支持路由刷新（如 SPA 的 history 模式）
Blazor Server 容器化（需完整 .NET 环境）
它运行在服务器端，依赖 .NET 运行时、Kestrel 和 SignalR 实时连接，必须用 ASP.NET Core 托管镜像。
- 确保项目是
Microsoft.AspNetCore.Components.Web框架下的标准 Blazor Server 模板 - Dockerfile 使用
mcr.microsoft.com/dotnet/sdk:8.0构建，再用mcr.microsoft.com/dotnet/aspnet:8.0运行 - 注意开放端口（默认 80/443）、配置
ASPNETCORE_URLS=http://+:80、设置ASPNETCORE_ENVIRONMENT=Production - 若用反向代理（如 Nginx），需额外配置 WebSocket 升级头（
Upgrade $http_upgrade和Connection "upgrade"）
通用注意事项
无论哪种模式，都要关注构建上下文、多阶段构建和运行时安全。
- 用多阶段 Dockerfile：第一阶段用 SDK 编译，第二阶段用 Runtime 镜像复制产出，减小最终镜像体积
- 避免在镜像中保留源码或调试符号；生产镜像用
--no-restore --no-self-contained发布 - 敏感配置（如 ConnectionStrings）不要硬编码进镜像，改用环境变量或挂载配置文件
- Blazor WebAssembly 若调用后端 API，注意跨域（CORS）策略和容器网络连通性（如后端是否同 docker network）
快速验证示例（WebAssembly）
一个最小可用的 Dockerfile：
FROM nginx:alpine COPY bin/Release/net8.0/publish/wwwroot /usr/share/nginx/html COPY nginx.conf /etc/nginx/nginx.conf EXPOSE 80
配合简单 nginx.conf 启用 history fallback：
location / {
try_files $uri $uri/ /index.html;
}
构建运行：docker build -t my-blazor-app . && docker run -p 5000:80 my-blazor-app
基本上就这些。选对模式、分清动静态、配好网络和反代，Blazor 容器化并不复杂，但容易忽略 SignalR 或路由重写这类细节。
