选择渲染模式之前
Blazor 实际上是什么
Blazor 是 Microsoft 的 .NET Web 应用程序组件框架。您可以从 Razor 组件构建 UI，用 C# 编写大部分交互逻辑，然后让 ASP.NET Core 在服务器、WebAssembly 或本机应用程序 shell 中呈现这些组件。
它源自较早的 ASP.NET 想法。 Web 窗体试图将 Web 隐藏在服务器控件后面。 MVC 和 Razor Pages 使请求-响应 HTML 更加清晰。 Blazor 添加了可重用的交互组件，但对于简单的内容页面和表单来说，它并不会使 MVC 或 Razor Pages 过时。
Web Forms、MVC 和 Razor Pages 解决了不同的问题
Web 表单非常高效，但笨重且有状态。 MVC 和 Razor Pages 提供了更清晰的 HTML 和更简单的请求处理。当页面主要读取数据、发布表单并返回 HTML 时，它们仍然很好。
组件使 UI 逻辑接近标记
Razor 组件可以包含标记、参数、事件、验证、注入服务和本地状态。这对于页面更改而无需完全重新加载的仪表板、编辑器、向导、网格和工具非常有用。
现代 .NET 允许您混合渲染模式
较新的 Blazor 应用程序可以将静态服务器渲染的 HTML 与交互式组件结合起来。这很重要，因为一个页面可能需要可爬行的内容，而另一部分需要实时组件。
目录
从这里开始
有用的简短版本
Blazor 不是一种架构。它是一个具有多种渲染模式的组件模型。正确的选择较少取决于语法，而更多地取决于状态、延迟、内存和可爬行链接所在的位置。
Blazor 服务器是有状态的
第一次加载时感觉很快，但服务器保持实时电路。在流量增长之前规划内存、重新连接行为和横向扩展。
WebAssembly 预先付款
它删除了实时服务器电路，但第一次访问会下载运行时和应用程序。缓存、修剪和预渲染很重要。
混合动力是产品决策
当应用程序确实需要桌面或移动 shell 时，请使用混合。对于公共内容，请使用 Web 渲染和真实 URL。
Blazor 服务器端
Blazor Server 在两次单击之间保持工作活动状态
Blazor Server 不是普通的无状态请求响应页面。连接的浏览器选项卡获得电路。当用户连接时，服务器会保留该电路的组件状态和范围服务，并且通常会在断开连接后的短暂重新连接窗口内保留。
记忆随着有源电路的增长而增长
每个连接的接头片都有一个电路。组件状态、作用域服务、验证状态和待处理的 UI 工作可以保留在内存中，直到电路结束。负载测试必须计算活跃用户数，而不仅仅是每秒的请求数。
延迟成为 UI 的一部分
按钮点击、输入事件或网格交互可能会往返于服务器。当观众分布在不同地区时，主持人应靠近用户并避免聊天内容。
横向扩展需要一个计划
多个应用程序实例通常需要粘性会话、SignalR 背板、Azure SignalR 服务或仔细的状态设计。否则，重新连接和带电电路可能会出现在错误的实例上。
适合：受控用户
Blazor Server 对于经过身份验证的工具、管理屏幕、仪表板和用户、延迟和托管容量已知的内部应用程序而言最为强大。
Blazor WebAssembly
WebAssembly 将成本转移到第一次加载
Blazor WebAssembly 消除了服务器电路，但并没有消除成本。浏览器必须下载 .NET 运行时、程序集、本地化资源和应用程序资产，才能获得快速体验。重复访问可能会很好，因为缓存会有所帮助。初次就诊需要护理。
第一个负载是税
浏览器下载 .NET 运行时、应用程序集、资源和静态资产。修剪有帮助。提前编译可以改善 CPU 密集型工作，但通常会增加下载大小。
秘密不能存在于客户端
WebAssembly 应用程序在用户的浏览器中运行。像任何公共前端一样对待它：在服务器上保守秘密，保护 API，并假设可以检查客户端代码。
SEO需要渲染内容
对于公共文章、产品页面和登陆页面，不要依赖仅在 WebAssembly 启动后才变得有用的空白外壳。使用服务器端渲染、预渲染、静态渲染或单独的内容路径。
适合：离线或客户端较多的应用程序
当用户经常返回、需要离线行为或执行繁重的客户端工作（而服务器往返会更糟糕）时，WebAssembly 效果很好。
混合和 WebView
混合适用于应用程序，不适用于公共登陆页面
当 .NET 团队想要在桌面或移动应用程序中重用组件时，Blazor Hybrid 非常有用。它通过 WebView 在本机 shell 中运行，因此可以接近本地文件、设备 API 和企业部署。它不是专注于 SEO 的网站的捷径。
- 当您需要访问本地文件、设备 API、桌面部署或移动打包时，请使用混合。
- 不要选择混合只是为了重用 Web 组件。本机 shell 添加了更新、存储、签名和支持工作。
- 对于 SEO 和可共享的公共 URL，混合通常是错误的表面。
多语言路由
具有文化意识的链接必须是真实的链接
多语言 Blazor 网站不应在页面变为交互式后仅在点击处理程序或 JavaScript 中构建语言导航。搜索引擎和用户需要在初始 HTML 中提供真正的锚标记，以及稳定的 href 值、规范 URL 和 hreflang 数据。
- 使用中央页面链接和帮助程序，而不是手动构建的字符串，例如斜线文化斜线路径。
- 在初始 HTML 渲染期间，将语言链接渲染为具有 href 值的锚标记。
- 保持规范 URL、hreflang URL 和可见语言导航同步。
- 避免将重要链接隐藏在 onclick 处理程序、延迟的 JavaScript 或纯交互式 Blazor 状态后面。
决策指南
根据您接受的瓶颈进行选择
每种渲染模式都会将压力转移到不同的地方。选择你可以衡量、主持并向团队解释的压力。
首次加载和 .NET 后端集成何时最重要
为受控的身份验证应用程序选择 Blazor 服务器，其中服务器内存、实时连接和区域延迟是可以接受的运营成本。
当客户的工作和线下行为最重要时
当重复访问、缓存、离线使用或本地 CPU 工作比最小的首次负载更重要时，请选择 WebAssembly。
当产品确实是原生应用程序时
当应用程序属于桌面或移动设备并且比公共网络覆盖范围更需要本地集成时，请选择混合。
当网站主要是文档和表格时
对于内容较多的网站、公共文档和交互性有限的表单来说，经典 ASP.NET Core MVC 或 Razor 页面通常更简单。
参考部分
当你真正构建这个时，请阅读接下来的内容
这些参考在做出架构决策后非常有用，因为它们涵盖了使 Blazor 页面在生产中可靠的部分：元数据、语言链接、托管和可重用 UI。
当每个页面需要一致的标题、描述、开放图谱、规范和 JSON-LD 输出时，请使用此选项。
SEO 友好语言-区域链接当多语言路由需要真正的可爬行链接、稳定的文化路径和正确的 hreflang 输出时，请使用此选项。
在 UpCloud 托管 Blazor当 Blazor 服务器应用程序需要小型 VPS、Nginx、TLS、systemd、日志、备份和可重复部署时，请使用此选项。
TablerForNet当值是管理界面、数据表、表单和仪表板屏幕而不是营销页面时，请使用此选项。
Blazor如果您希望在选择下一个实施细节之前将相关指南放在一个位置，请使用 Blazor 中心。
常见问题
为什么 Blazor Server 需要比 MVC 更多的内存？
MVC可以完成一个请求并释放大部分请求状态。 Blazor Server 为每个连接的浏览器选项卡保留一条线路，因此组件状态和作用域服务可以在单击之间保持活动状态。
我可以在多个应用实例上运行 Blazor Server 吗？
是的，但是要仔细计划。实时电路和 SignalR 连接需要稳定的路由、背板或托管 SignalR 服务以及能够正确重新连接的应用程序状态。
Blazor WebAssembly 是否适合 SEO？
是的，但不是通过运送一个空壳并希望爬虫等待。公共页面需要在第一次响应之前或期间呈现 HTML、元数据、规范链接和结构化数据。
应如何构建多语言 Blazor 链接？
使用中心路线定义并为每种文化呈现真实的锚标记。保持可见链接、规范 URL 和 hreflang 数据对齐，以便用户和爬虫看到相同的语言结构。