整体流程故事就是这样，但这里有一个核心点需要我们关注：服务端是怎么生成blazor.webassembly.js的？

过程分如下三步走

1. 在项目编译期，所有 Razor 页面，也就是 Blazor 组件，也就是*.razor文件，都被转译成了 C#文件，然后进一步的，编译成了 dll 中的 IL 代码。也就是一个名为HelloRazor.dll的可执行二进制
   • 是的，你没有看错，.Net Core 项目的可执行二进制的后缀依然是*.dll。。
     • 这种可执行比较怪，或许不应该叫“可执行二进制”：对于一般的 console application，由于不牵涉额外的运行时依赖的特殊类库，可以直接用dotnet *.dll方式运行，但对于一些复杂应用，比如 Blazor App，直接以dotnet *.dll试图运行时可能会找不到对应的运行时依赖库
   • 如果你想得到 Windows 下标准的 PE 可执行二进制文件(*.exe)，或 Linux 下标准的 ELF 可执行二进制，需要进一步的使用dotnet publish命令进行发布
   • 发布的过程，其实就是把编译产生的*.dll文件包装成了一个 PE 文件或 ELF 文件，就是套了一层壳子，外加把依赖库集中放置在身边 -- 或者self-contained形式的话整体打成一个二进制
2. 在项目编译期，上一步编译出来的 Blazor 组件类，被打包转译成了 Web Assembly 代码。再然后连同.Net 的一些类库也被打包成 Web Assembly 代码，最后全捏在一起，形成了一个blazor.webassembly.js，并放置在运行目录的wwwroot子目录中
3. 在项目运行期，上一步生成的blazor.webassembly.js就变成了一个在wwwroot目录下托管的普通静态资源，变得与index.html别无二致

这其中我们要重点关注第一步，即要关注一个我们从上一篇文章就强调的概念：Blazor 组件，其实就是 C#类，只不过书写成了*.razor这种形式。我们要重点关注，这个从*.razor到*.cs的转译过程中，发生了什么。了解这背后的机理，有助于我们理解*.razor中一些奇怪的语法。

至于第二步，我们作为框架的使用者，没必要去过分关心。有两个理由：

1. 在 Blazor WASM（WASM 即是 Web Assembly 的缩写，后续文章不再说明）工作方式中，交互逻辑才需要被转译成 WASM 代码下发给浏览器。而在 Blazor Server 工作方式中，交互逻辑直接在 Web Server 端执行，不需要转译。过分关注从 C#到 WASM 的转译过程只对 Blazor WASM 工作方式的应用有用，对 Blazor Server App 是没有意义的
2. 这部分知识过于艰深晦涩，并且对业务开发几乎没有任何意义

在执行了dotnet build后，项目目录下就会默认的生成两个子目录：obj和bin，这两个目录下有海茫茫的文件与目录，目录你可以这样简单的理解这两个目录：

• obj: 存放编译产物与中间产物，包括编译前必要的一些准备工作所需的临时文件等
• bin: 可执行二进制。比如在bin目录下除了会有可执行二进制外，还会有wwwroot目录存储着运行时需要托管的静态资源（包括生成的blazor.webassembly.js，以及运行时所需的相关库文件）

对于我们这个项目来说，有两个编译产物需要关注

1. obj/Debug/net6.0/HelloRazor.dll和bin/Debug/net6.0/HelloRazor.dll，可以认为这两个文件是同一个文件。后续文章将直接以HelloRazor.dll来描述
2. bin/Debug/net6.0/wwwroot/_framework/blazor.webassembly.js。这个是最终生成的 Web Assembly 代码

我们上面说了，*.razor文件会被先转成*.cs，然后再编进二进制中。但在 Blazor WASM 工作模式下，中间那一步是不可见的，即obj目录下是没有App.cs和Index.cs这样的中间文件的：它们被一步到位的编译进了HelloRazor.dll中

Razor 代码与 IL 代码

没有中间的*.cs文件，意味着我们没法直接观察中间的*.cs长什么样子。但有个比较曲折的方式：我们可以使用反编译工具ILSpy，去查看由 IL 代码反编译生成的 C#代码长什么样。

下面是HelloRazor.dll的反编译结果：

首先是整个 dll 中包含了三个类：Program是我们写的入口类，App和Index则是 Razor 代码生成的类：

App类

以下是App.razor的内容

@using Microsoft.AspNetCore.Components.Routing


    
        
    
    
        
Page Not Found
    

下面是反编译的App的类

// HelloRazor.App
using HelloRazor;
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.CompilerServices;
using Microsoft.AspNetCore.Components.Rendering;
using Microsoft.AspNetCore.Components.Routing;

public class App : ComponentBase
{
	protected override void BuildRenderTree(RenderTreeBuilder __builder)
	{
		__builder.OpenComponent(0);
		__builder.AddAttribute(1, "AppAssembly", RuntimeHelpers.TypeCheck(typeof(App).Assembly));
		__builder.AddAttribute(2, "Found", (RenderFragment)((RouteData routeData) => delegate(RenderTreeBuilder __builder2)
		{
			__builder2.OpenComponent(3);
			__builder2.AddAttribute(4, "RouteData", RuntimeHelpers.TypeCheck(routeData));
			__builder2.CloseComponent();
		}));
		__builder.AddAttribute(5, "NotFound", (RenderFragment)delegate(RenderTreeBuilder __builder2)
		{
			__builder2.AddMarkupContent(6, "
Page Not Found
");
		});
		__builder.CloseComponent();
	}
}

通过对比，不难看出一些一一对应的行。我们也可以简单的总结一些规律

App.razor是一个前端路由器，虽然书写上均是 XML 元素+属性的形式，但用到的元素和属性都不属于 HTML 的范畴。这里，我们可以把非 HTML 范畴的 XML 元素标签或属性简单的理解为Blazor 框架内部为我们已经实现的组件。

比如很明显的：

• 就对应着OpenComponent，我们可以理解为 Blazor 框架内部为我们实现了一个名为Router的组件
• 和虽然也是 XML 元素，但对应的 C#代码其实是Router组件中的一个属性
• 对应着OpenComponent，可以理解这是一个名为RouteView的组件

除了这种组件，还有一行特别瞩目：

• Page Not Found

  被转译成了AddMarkupContent(.., "

  Page Not Found

  ")

根据这个，我们目前可以简单的认为，*.razor中原生的 HTML 代码其实是被直接以字符串的形式转译过去的。

关于这一点，我们可以在 Index.razor中得到验证

Index 类

以下是Index.razor的内容：

@page "/"

Hello, Razor!

This is a Razor page, but only contains standard HTML code.

以下是反编译的Index类的代码：

// HelloRazor.Index
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Rendering;

[Route("/")]
public class Index : ComponentBase
{
	protected override void BuildRenderTree(RenderTreeBuilder __builder)
	{
		__builder.AddMarkupContent(0, "
Hello, Razor!
\r\n\r\n");
		__builder.AddMarkupContent(1, "
This is a Razor page, but only contains standard HTML code.
");
	}
}

这就简直没什么悬念了，我们可以暂时总结出下面三条规律：

1. 原生的 HTML 代码会被转译成AddMarkupContent，以字符串的形式喂给__builder
2. Blazor 框架已经为我们实现了一些组件，这些组件均会被转译成OpenComponent
3. 组件中的属性，一部分以*.razor中以 XML 属性的形式出现，一部分以子元素的形式出现

另外，虽然我们不清楚__builder的具体实现，也没必要去过分纠结，但有一点可以肯定的是：它内部是一个树型的数据结构，它就是对标于 React 框架中的 Virtual Dom 概念的一个东西，它最终的渲染结果，其实就是代表着最终视觉效果的 DOM

3. 基础的 Razor 语法

在了解了一些浅薄的 Razor -> C#的知识后，我们终于可以开始介绍 Razor 这套标记语言的语法了。本小节将在上一小节的示例项目的基础上，循序渐进的讲解一些基础的 Razor 语法

3.1 Razor 表达式 = 在 Razor 页面中写 C#表达式 : @xxx与@(xxx)

在 Razor 页面中可以书写 C#表达式，最终呈现的渲染结果将对表达式进行求值，比如我们可以把Index.razor改写成如下模样：

@page "/"

Hello, Razor!

Current Time Is @DateTime.Now.ToString()

最终呈现效果如下：

语法很简单，就是在一个@后加一个合法的 C#表达式，即可。

表达式最终会被隐式的调用ToString()转成字符串（也就是说上面显式的调用ToString()是不必要的），并且为了避免注入，也会对字符串进行转义处理。这都没什么好说的，比较容易理解。

而除过记住这个语法，更重要的是去理解，这种语法在 C#类那边，被转译成了什么样子。下面是更改后，对应的 C#类在 ILSpy 中的样子(using语句已略，后方不再说明)：

[Route("/")]
public class Index : ComponentBase
{
	protected override void BuildRenderTree(RenderTreeBuilder __builder)
	{
		__builder.AddMarkupContent(1, "
Hello, Razor!
\r\n\r\n");
		__builder.OpenElement(1, "p");
		__builder.AddContent(2, "Current Time Is ");
		__builder.AddContent(3, DateTime.Now.ToString());
		__builder.CloseElement();
	}
}

这里我们接触到了新的方法：OpenElement，显然它是用来转译 HTML 原生元素用的。而 C#表达式则被转译成了AddContent。如果你仔细阅读了上一章节的内容，这里你应该相当豁然开朗，甚至如果你有相关编译原理知识的功底，知道如何写一个 Parser 的话，你大致已经有了一个“自己写一个 Razor 引擎转译器”的思路了

一些额外知识点：

0. 有些人会把 Razor 文件转译器叫做 Razor 引擎，而有些人会把从转译到整个渲染运行的所有相关的类库加在一起，叫Razor 引擎，我可能在后续文章中不会特别区别，可能会混着叫，大家按上下文自行甄别
1. @代表着 Razor 引擎会把后续当作是一个 C#表达式去处理。而如果你真的想输入一个@字符的话，连续写两个@@就可以了
2. Razor 引擎也并不是简单无脑的把所有@字符后面的后续当成 C#表达式去处理，一些场景它会智能分析，比如像damn@wtf.com这种情形，它就能自动分析出来这是电子邮件地址，而不做表达式求值
3. 表达式中间是不能有空格的，比如

   @DateTime. Now. ToString()

   是非法的，引擎仅会把DateTime当成表达式，而由于这是一个类型，不是一个合法的表达式，编译期就会把这种错误检查出来。 但有时候恰巧加个空格导致一个残疾的表达式在语法上是合法的，这种错误可能就只能等到运行期才可能报错了。
4. 要使用复杂的、包含空格或者其它杂技的表达式，一个很简单的方法：加括号，比如

   @(DateTime. Now. ToString())

   就是合法的。这种由@(xxx)将表达式整个括起来的写法，被称为Explicit Razor Expression，我将称其为显式表达式，而不加括号的简便写法，叫Implicit Razor Expressions，我将称其为隐式表达式
5. 隐式表达式是无法使用泛型的，典型的就是调用泛型方法。比如

   @GenericMethod()

   ，这是非法的。这是由于 Razor 引擎无法区分泛型表达式中的尖括号，与 HTML 元素、Blazor 组件的尖括号。这时你只能使用显式表达式，如

   @(GenericMethod())

6. 默认情况下，表达式求值后，会调用ToString()转成字符串，再被脱敏进行防注入。意味着

   @("

   Header?

   ")
   最终求值的结果其实是"<h1>Header?</h1>"。而如果你真的想作大死，就是要输出 HTML 标签，那么你可以使用@((MarkupString)("

   Header?

   "))这种方式。其中MarkupString是一个类型，全名为Microsoft.AspNetCore.Components.MarkupString，其实就是加一个强制类型转换。。但强烈建议不要这么作死。

3.2 待续

鉴于博客园的markdown编辑器已经开始卡顿了，并且这篇文章已经足够长了，我们就把其它Razor基础语法放在下一篇文章中再介绍吧。

有好奇心的同学其实已经可以顺着这个思路去官网查文档学习Razor Syntax了。没必要非得等我写教程

4. 指正与更正

4.1 评论指正总结

总结一下：

1. razor是先进的，我个人对其有着不正确的评价。描述UI势必就要把JS/TS或其它什么程序设计语言，和HTML&CSS掺在一起写。。。到底是面里掺水还是水里掺面，其实大家掺完都长一个逼样。。要说丑，大家都丑。
   Razor也只是长的像JSP，其实比JSP这种货色不知道高到哪里去了。

2. 文中最大的错误在于对webassembly.js的解释是完全错误的：它并不是前端那种打包后的bundle.js，它里面没有Blazor组件的代码，它也不是WASM代码。
   WASM项目打包后其实有三层：webassembly.js->dotnet.wasm->*.dll，这三层摞在一起才相当于传统前端打包后的那个bundle.js
   我可以用是，我知道。我这是在简化问题，先隐去一些细节，目的是之后展示更大的图景。这句来源于《C# in depth》的话来狡辩，但这个错误确实太硬了，没法洗。

3. 关于Kestrel和Web Server。
   WASM项目打包后，和其它前端项目一样，就是一堆静态文件。
   但在开发时，本地势必要起个dev server，前端那边用的是webpack dev server，Blazor这边用的是自己写的web server：一个内部使用Kestrel库的web server。

4.2 工具链生成的C#代码

在.net 5及以前的版本中，obj中间目录会有Blazor组件对应的C#代码存在，.net 6后就把这些中间产物移除了（不让我们直接看了），可能是工具链做了某些调整。

位置是obj/Debug/net5.0/Razor/...，生成的C#代码掺杂了大量的注释，可读性不高，不如直接用ILSpy反着看紧凑。

一个默认模板项目中的App.razor会被转译成下面这样：