我很困惑Razor组件和Blazor之间有什么不同，哪个更好，在上一个版本.NET Core 3.0 Preview 3中添加了Razor组件
Razor组件改进：
基本上有三个部分需要理解。
剃刀组件
对于服务器端Blazor的第一个版本，这是在2018年7月创建的核心，进程外组件模型的名称。
Razor Components是框架的核心，包含以下所有内容。
服务器端Blazor
这是在ASP.NET Core上运行的服务器端托管模型，用于Razor组件。此版本在服务器上托管Razor组件模型。它使用一个小型运行时将UI事件从浏览器发送到服务器。一旦由Razor组件处理，任何UI更新都会从服务器发送回浏览器，运行时处理更新DOM。所有这些通信都通过SignalR连接进行处理。甚至JS互操作调用都是以这种方式处理的。
客户端Blazor
这是Razor Components的客户端托管模型。
在此模型中，所有内容都托管在浏览器中。编译为WebAssembly的Mono是.NET运行时。最重要的是Razor Components，然后是应用程序。
这个体系结构的优点在于，理论上，Razor组件中添加的任何功能都应该可用于托管模型。虽然实际上并非总是如此。
什么更好？
这在很大程度上取决于你想做什么。
客户端Blazors最大的缺点是它的下载大小。仅这一点就可以为许多开发人员排除它。下载很容易分成多个MB，如果有人试图通过慢速连接在移动设备上查看您的应用程序，他们将无法获得良好的体验。但是，值得注意的是，在第一次下载后，大量内容被缓存，因此后续加载可能只有几百kb。
客户端Blazors的调试经验现在也非常原始。这意味着作为开发人员进行工作有时可能会遇到挑战。
服务器端Blazor在调试方面拥有更好的开发人员经验。该应用程序的下载速度要快得多，并且在进行任何缓存之前只有几百克的大小。
缺点是潜在的可扩展性。但这在很大程度上取决于您期望的并发用户数。因为此模型使用SignalR，您的应用程序将对并发连接有一个上限。但是，您可以通过插入Azure SignalR来管理这一点，以允许与您的应用程序建立更多的连接。
最终，Razor Components的托管模型还有很长的路要走。两者的身份验证故事都处于早期阶段，尽管客户端Blazor可以说是处于更好的地方。路由引擎仍然有限，表单和验证只是刚刚发布它的第一个版本，还有工作要做。
另外要记住的是，可以很容易地在模型之间进行切换。所以无论你做出什么样的决定，你都没有被束缚。甚至有一种方法可以在某个时刻内置到框架中，所以你现在所做的一切都不会浪费。
如有任何问题，请询问。但我希望这会有所帮助。
Razor Components是一个框架，您可以使用它创建SPA Web应用程序。它分为两种执行模式。当Web应用程序在浏览器上托管和执行时，它被称为Blazor。 Blazor应用程序是用C＃编写的，并编译成.NET程序集。它们作为.NET程序集在Mono运行时执行并在浏览器上运行，它本身被编译为Web程序集。
第二种执行模式是服务器端。也就是说，您的Web应用程序在服务器上执行，而不是在浏览器上执行。请注意，此处运行时环境不是Mono Web Assembly，而是Asp.net Core运行时。这被称为服务器端Blazor，但也使用了Razor Components这个术语，因此困惑变得困惑。其原因是历史性的：开始时，只有Blazor在浏览器上运行。但后来认为Web应用程序可以在服务器上运行，只有差异可以通过SignalR发送到浏览器。在服务器上运行Web应用程序比在浏览器上运行要容易得多，并且开发人员可以使用他在浏览器上无法使用的许多元素，例如调试等。由于这种可能性，Asp.Net重命名Blazor框架作为Razor组件，您可以将其视为Blazor构建的超级结构。这就是混乱的原因。让我们强调这个划分如下：
剃刀组件 - > Blazor（前端;浏览器）
剃刀组件 - > Razor组件（服务器端Blazor）
我知道这是混乱的根源，但这就是......
至于更好的问题，我可能只会说它完全取决于你的要求。这些执行模式中的每一种都有其优点和缺点。 Blazor应用程序更适合作为公共网站在Internet上运行，而服务器端Blazor应用程序最好在Intranet上用作企业网站。
您显示的列表与Razor Components框架有关。暂时的一些改进可能只与Blazor有关，而其他改进与服务器端Blazor有关。只有一种方法可以知道哪个是：学习剃刀组件。学习它需要时间，而不是Angular，特别是如果你是.Net开发人员，但它仍然需要一些投资。
希望这会有所帮助......我稍后会对此进行改进，但如果您有具体问题，请不要犹豫......