blazor的server、wasm和auto三种模式本质是代码运行位置、状态存储位置与连接方式的组合：server模式代码在服务端、依赖signalr长连接；wasm模式代码全下载至浏览器、离线可用但首屏慢；auto模式首屏server渲染并后台加载wasm，完成后自动切换。
Blazor 的 Server、WASM 和 Auto 三种呈现模式，本质是“代码在哪跑、状态在哪存、连接怎么建”这三件事的不同组合——选错模式，不是卡顿就是加载失败，不是部署炸裂就是离线瘫痪。
Server 模式：代码全在服务器，靠 SignalR 推 ui
它不把 .NET 运行时发给浏览器，只发 HTML + 一个极小的 blazor.server.js，靠 SignalR 维持长连接。每次点击按钮，事件发到服务端，服务端算完再把 dom 差分更新推回来。
- ✅ 适合内网系统、低配终端（树莓派/老平板）、IE11 以外的任意现代浏览器
- ❌ 网络一抖就假死；断连后必须刷新；服务器内存随在线用户线性涨（1 万用户 ≈ 数 GB 内存）
- ⚠️ 负载均衡必须开粘性会话（
ASPNETCORE_FORWARDEDHEADERS_ENABLED=true+ 反向代理配置），否则 SignalR 连接乱跳导致状态丢失 - ? 启用方式：Program.cs 中调用
AddServerComponents()，App.razor 里写@rendermode InteractiveServer
WASM 模式：代码全下到浏览器，自己算自己
整个 .NET 运行时（约 5–8 MB）+ 你的 DLL 打包成 WebAssembly，首次加载慢，但之后所有交互都在本地跑，不依赖后端连接。
- ✅ 支持离线、无 websocket 依赖、服务器零压力、CDN 静态托管即可（nginx / azure Static Web Apps）
- ❌ 首屏白屏久（尤其 3G/弱网）；低端安卓手机可能卡在下载阶段；敏感逻辑（如密钥计算）暴露在 F12 里
- ⚠️ 必须补 API 层：不能直接调 EF Core 或数据库连接，得走
HttpClient调后端控制器，CORS、Token、DTO 全得自己搭 - ? 启用方式：Program.cs 用
AddWebAssemblyRenderMode()，_Host.cshtml 引入blazor.webassembly.js，组件用@rendermode InteractiveWebAssembly
Auto 模式：首屏 Server 渲染，自动升级 WASM（.NET 8+）
它不是“自动选”，而是“有策略降级+渐进升级”：首次 GET 请求走 Server 预渲染（快），同时后台静默下载 WASM 资源；一旦 wasm 加载完成且 SignalR 连接稳定，后续交互自动切到客户端执行。
- ✅ 解决 WASM 首屏慢 + Server 断连不可用两大痛点；爬虫/无 JS 环境自动回退静态 SSR
- ❌ 不是“一次配置，永远省心”：你得在 _Host.cshtml 同时引用
blazor.server.js和blazor.webassembly.js，并设autostart="false"让框架接管启动时机 - ⚠️ 若你删了
MapBlazorHub()或没注册AddAutoRenderMode()，Auto 就退化成纯静态渲染（按钮点不动） - ? 关键三步：
AddAutoRenderMode()+app.MapBlazorHub()+ App.razor 里@rendermode Auto；组件可细粒度用@rendermode InteractiveAuto
最常被忽略的一点：Auto 模式下，NavigationManager 的行为在 Server 阶段和 WASM 阶段不一致（比如 NotifyLocationChanged 触发时机），如果你手动监听路由或做 SPA 跳转拦截，务必加 if (JSRuntime is not NULL) 判断执行环境，否则 Server 阶段会抛 NullReferenceException。