主要的区别在于你的.NET代码运行的位置：使用Blazor Server，它是100%服务器端；而使用托管的Blazor WASM应用程序，则.NET代码在服务器和客户端上都运行（尽管服务器也可以运行任何其他语言或框架）。
据我所读，我了解到Blazor服务器端和Blazor WebAssembly Hosted都有服务器端代码，但它们看起来不同。
- Blazor Server应用程序的.NET运行时是100％服务器端的。客户端使用框架JS库与服务器通信，但归根结底，您将获得一个.NET应用程序。
- 对于Blazor WASM，您的客户端在浏览器中运行单独的.NET运行时。除了客户端WASM应用程序外，托管模型还会生成一个.NET Web API服务器项目；但是，您可以使用任何后端技术来提供和增强您的客户端应用程序（例如Node.JS上的Express），因为您的客户端是服务器技术无关的。
并非总是如此。Blazor Server需要Signal R来持续通信和更新客户端，但Blazor WASM更加灵活。从
docs中可以看出：
托管的客户端应用程序可以使用各种消息框架和协议（例如
Web API，
gRPC-web和
SignalR）通过网络与其后端服务器应用程序进行交互。
同样，Blazor WASM对您的服务器端是不可知的。托管模型为您生成了一个服务器端，但您可以在技术上使用任何您想要的东西。
这些的客户端部署在哪里？
Blazor Server并没有编译客户端：一旦连接到应用程序，它就利用Signal R通过Web套接字（或其他技术，当不可用时）持续向客户端推送更新。
Blazor WASM是客户端：当您编译WASM项目时，类似于运行Webpack针对React应用程序。 Blazor WASM是一种前端技术，因此可以作为静态网页的依赖项提供，也可以通过Web API进行增强和服务，例如使用托管模型。
它们与服务器的连接有什么区别？
再次说明，Blazor Server需要Signal R，而Blazor WASM是技术无关的：它可以使用Signal R，但通常您只需要标准的HTTP协议。
如果Web应用程序调用第三方Web API，该调用如何路由？
这是一个完全不同的问题，但我可以看到混淆。您的WebAPI是完全独立的应用程序；如果它进行外部请求，您的WASM应用程序将毫不知情。
文档提供了以下见解（请注意，这并没有区分WASM的两个模型，但仍然适用）：
当使用 Blazor WebAssembly 应用程序进行部署时，如果没有后端 ASP.NET Core 应用程序来提供其文件，则称该应用程序为
独立 Blazor WebAssembly 应用程序。当使用后端应用程序来提供其文件进行部署时，则称该应用程序为
托管 Blazor WebAssembly 应用程序。
Blazor WebAssembly (WASM) 托管模型具有以下几个优点：
- 应用程序在从服务器下载后没有 .NET 服务器依赖项，因此，如果服务器离线，则应用程序仍然可以正常工作。
- 充分利用客户端资源和功能。
- 将工作从服务器卸载到客户端。
- 无需 ASP.NET Core web 服务器即可托管应用程序。 > - 可以在无服务器部署方案中实现，例如从内容交付网络 (CDN) 提供应用程序。
Blazor WebAssembly 托管模型有以下限制：
- 应用程序受浏览器能力的限制。
- 需要强大的客户端硬件和软件 (例如，WebAssembly 支持)。
- 下载大小更大，应用程序加载时间更长。
与 Blazor Server 相比：
Blazor 服务器托管模型提供了多个优势：
- 下载大小比 Blazor WebAssembly 应用程序明显更小，应用程序加载速度更快。
- 应用程序充分利用服务器功能，包括使用 .NET Core API。
- 在服务器上使用 .NET Core 运行应用程序，因此现有的 .NET 工具（例如调试）可以按预期工作。
- 支持轻量客户端。例如，Blazor Server 应用程序可与不支持 WebAssembly 的浏览器以及资源受限设备配合使用。
- 应用程序的 .NET/C# 代码库（包括应用程序的组件代码）不会提供给客户端。
Blazor Server 托管模型具有以下限制：
- 通常存在较高的延迟。每个用户交互都涉及网络跳跃。
- 没有离线支持。如果客户端连接失败，则应用程序停止工作。
- 扩展具有许多用户的应用程序需要服务器资源来处理多个客户端连接和客户端状态。
- 需要 ASP.NET Core 服务器来提供应用程序。无法进行无服务器部署方案，例如从内容传递网络 (CDN) 提供应用程序。
