第1章 先和编译器交个朋友：它到底在干嘛？

你有没有过这样的经历：写完一段Python代码，敲下回车就能立刻看到结果；而写完一段C代码，需要先执行`gcc hello.c`，再运行生成的`a.out`，才能得到同样的输出？这两种看似天差地别的运行方式，背后都站着我们今天要认识的主角——编译器（Compiler）和它的好兄弟解释器（Interpreter）。

如果把写代码比作用中文写小说，那编译器就是全职翻译官：你得把整本小说（源代码）交给他，他会在后台吭哧吭哧翻译很久，最后给你一本完整的英文版（可执行文件），你拿起来就能直接读，不需要再找翻译。而解释器就是同声传译：你说一句中文，他马上翻译一句英文给听众，不用等整本小说翻完，但听众想再看一遍刚才的内容，还得让他再翻译一次。

---

1.1 编译器 vs 解释器：不是非黑即白的对立

很多人对两者的区别停留在“编译型语言快，解释型语言灵活”的浅层认知，实际上两者的核心差异是翻译时机的不同，甚至很多现代语言早就模糊了两者的边界。

1.1.1 核心差异的本质

我们可以用一个简单的公式概括两者的工作流程差异：

• 编译器工作流：`源代码 → [运行前全量翻译] → 可执行产物 → [直接执行] → 运行结果`
• 解释器工作流：`源代码 → [运行时逐段翻译] → 立即执行 → 运行结果`

举个最直观的例子：你要计算`1+2+3+...+100`的结果，用C语言（典型编译型语言）你需要先写代码、编译成可执行文件、再运行得到结果；用Python（典型解释型语言）你可以在交互式命令行里直接输入`sum(range(1,101))`，马上就能得到结果，不需要提前编译。

但这里有一个非常常见的误区：Python并不是“纯解释型语言”。CPython（官方Python实现）在运行代码前，会先把`.py`源代码编译成字节码（Bytecode）产物，存放在`__pycache__`目录下的`.pyc`文件中，之后运行相同版本的代码时，解释器会直接读取预编译好的字节码，不需要重新翻译源代码。这相当于同声传译提前把常用的稿子翻成了笔记，下次再读到相同的内容直接看笔记就行，速度自然快了不少。

而JS的V8引擎更是把“编译”和“解释”的边界彻底打破：它会先解释执行代码，同时统计哪些代码被反复执行（也就是“热点代码”），然后把这些热点代码编译成优化后的机器码，下次执行直接跑机器码，速度比纯解释快几倍甚至几十倍。这种混合模式被称为JIT（Just-In-Time，即时编译），现在已经成为动态语言的主流执行方案。

1.1.2 主流语言的运行模式对比

我们可以通过下表直观看到不同语言的运行模式差异，这张表也覆盖了90%以上你日常会接触的语言：

| 语言 | 运行模式 | 编译产物 | 执行主体 | 典型场景 | |------|----------|----------|----------|----------| | C/C++ | 静态编译（AOT） | 平台相关的机器码（ELF/PE/Mach-O格式） | CPU直接执行 | 操作系统、嵌入式、高性能服务 | | Rust | 静态编译（AOT） | 静态链接的机器码 | CPU直接执行 | 系统编程、WebAssembly、区块链 | | Go | 静态编译（AOT） | 静态链接的机器码 | CPU直接执行 | 云原生服务、命令行工具 | | Java | 静态编译+JIT | 平台无关的字节码（.class文件） | JVM解释/JIT执行 | 企业级后端、Android应用 | | Python | 混合编译+解释 | 平台相关的字节码（.pyc文件） | CPython虚拟机执行 | 脚本、数据科学、AI | | JavaScript | JIT编译 | 机器码 | V8/SpiderMonkey引擎执行 | 前端、Node.js服务、桌面应用 | | Swift | 静态编译+JIT | 机器码 | CPU直接执行 | iOS/macOS应用 |

> 📌 术语辨析：AOT（Ahead-Of-Time，提前编译） vs JIT（Just-In-Time，即时编译）：AOT是在程序运行前完成全部翻译，产物是独立的可执行文件；JIT是在程序运行时按需翻译热点代码，产物是内存中的机器码，不会生成独立的可执行文件。

---

1.2 编译器的内部结构：前中后端的分工协作

不管你是用GCC编译C，用rustc编译Rust，还是用V8执行JS，所有编译器的核心逻辑都可以拆成三个大模块：前端（Frontend）、中间端（Middle-End）、后端（Backend）。我们可以把编译器的工作流程比作一家跨国公司的项目交付流程：

• 前端是**需求分析师**：负责理解客户（程序员）的需求，把零散的需求整理成标准的文档；
• 中间端是**项目经理**：把不同需求分析师整理出来的文档统一成公司标准格式，去掉冗余内容，优化流程；
• 后端是**技术落地团队**：把标准格式的文档转换成客户所在地区（CPU架构）能看懂的具体实施方案。

1.2.1 前端：把源代码变成结构化语义

前端是编译器最“懂语言”的部分，它的核心任务是把人类可读的源代码转换成计算机可理解的结构化语义表示，一共分为三个步骤：

步骤1：词法分析（Lexical Analysis，也叫扫描Scanning）

词法分析器（Lexer/Scanner）是编译器的第一道关卡，它的工作非常简单：把连续的源代码拆成一个个独立的“词（Token）”。就像你读中文的时候，会自然地把一句话拆成一个个汉字、词语，不会把“编译原理”当成一个不可分割的整体。

我们拿最简单的C语言代码举例： ```c int a = 10; ``` 词法分析器会把这行代码拆成5个Token： 1. 关键字`int`（类型：KEYWORD） 2. 标识符`a`（类型：IDENTIFIER） 3. 赋值符`=`（类型：OPERATOR） 4. 数字常量`10`（类型：INTEGER_LITERAL） 5. 分号`;`（类型：DELIMITER）

你可能会问：这个拆分规则是怎么来的？答案是正则表达式（Regular Expression）——这也是本书书名里把正则表达式放在最前面的原因：几乎所有编译器的词法分析规则都是用正则表达式定义的。比如C语言的标识符规则可以写成正则`[a-zA-Z_][a-zA-Z0-9_]*`，意思是“第一个字符是字母或下划线，后面可以跟字母、数字、下划线”；数字常量的规则可以写成`[0-9]+`，意思是“一个或多个数字字符”。

我们可以用几十行Python代码实现一个最简词法分析器，直接运行就能看到分词效果： ```python import re

def simple_lexer(code: str) -> list[tuple[str, str]]:

定义词法规则：每个元素是(Token类型, 匹配正则)

token_spec = [ ('KEYWORD', r'int|return|void|if|else'), # 关键字 ('IDENTIFIER', r'[a-zA-Z_]\w*'), # 标识符 ('INTEGER', r'\d+'), # 整数 ('OP', r'=|;|\+|\-|\*|/|\(|\)'), # 操作符和分隔符 ('SKIP', r'[ \t\n]'), # 跳过空白和换行 ('MISMATCH', r'.'), # 匹配任意其他字符（报错） ]

合并所有正则，命名为对应的捕获组

token_regex = '|'.join(f'(?P<{name}>{pattern})' for name, pattern in token_spec) tokens = [] for match in re.finditer(token_regex, code): kind = match.lastgroup value = match.group() if kind == 'SKIP': continue if kind == 'MISMATCH': raise SyntaxError(f"非法字符: {value}") tokens.append((kind, value)) return tokens

测试

code = "int a = 10;" print(simple_lexer(code))

输出: [('KEYWORD', 'int'), ('IDENTIFIER', 'a'), ('OP', '='), ('INTEGER', '10'), ('OP', ';')]

``` 这个例子就是几乎所有词法分析器的核心逻辑：用正则匹配不同的词法模式，输出结构化的Token列表。如果你以后写DSL（领域特定语言），第一步就是定义好词法规则。

步骤2：语法分析（Syntax Analysis，也叫解析Parsing）

语法分析器（Parser）拿到词法分析器输出的Token列表后，会按照语言的语法规则，把这些Token组装成语法树（Syntax Tree）。语法树是一棵描述代码结构的树，每个节点对应一个语法规则，比如“赋值语句由标识符、赋值符、表达式组成”。

我们还是拿`int a = 10;`举例，它的语法树（也叫具体语法树CST，Concrete Syntax Tree）会保留所有语法细节，比如分号、类型声明的位置： ```mermaid graph TD A[声明语句 Declaration] --> B[类型 int] A --> C[赋值语句 Assignment] C --> D[标识符 a] C --> E[表达式 Expression] E --> F[整数 10] C --> G[分号 ;] ``` 但具体语法树有一个很大的问题：它包含了太多和语义无关的语法细节，比如括号、分号、类型声明的关键字，这些内容在后续的语义分析和优化中完全用不到。因此语法分析器通常会在生成CST之后，转换成更精简的抽象语法树（Abstract Syntax Tree, AST），去掉所有语法冗余，只保留核心语义结构。刚才的代码对应的AST是这样的： ```mermaid graph TD A[变量声明 VarDecl] --> B[变量名 a] A --> C[初始值 10] ``` AST是编译器后续所有步骤的核心数据结构，不管是做语义检查、优化还是生成机器码，都是在操作AST。你可以把AST理解为“编译器能看懂的代码结构”，它和人类写的代码看起来完全不一样，但包含了所有需要的信息。

> 💡 小知识：为什么很多IDE的语法高亮、代码格式化工具速度很快？因为它们只做了词法分析和轻量级的语法分析，不需要生成完整的AST，也不需要做后续的优化和机器码生成，所以速度极快。

步骤3：语义分析（Semantic Analysis）

拿到AST之后，编译器需要检查代码的语义是否正确，也就是“代码写的东西是不是符合逻辑”。比如你不能把字符串赋值给int类型的变量，不能调用一个不存在的函数，不能对布尔值做加法运算。语义分析器会遍历AST，检查类型、作用域、符号定义等语义规则，如果发现问题就会抛出编译错误。

比如下面的C代码： ```c int a = "hello"; // 错误：字符串不能赋值给int类型变量 ``` 词法分析和语法分析都会认为这行代码是正确的（符合语法规则），但语义分析器会发现类型不匹配，直接报错。

1.2.2 中间端：跨架构的通用翻译标准

前端处理完源代码之后，生成的是和语言强相关的AST，比如C的AST和Rust的AST结构完全不同，如果后端直接处理不同语言的AST，就需要为每种语言写一套后端逻辑，成本极高。因此编译器引入了中间表示（Intermediate Representation, IR）作为前端和后端之间的通用标准。

IR是一种简化的、平台无关的指令集，它不像源代码一样有复杂的语法糖，也不像机器码一样和特定CPU架构绑定。最知名的IR是LLVM IR，它是LLVM编译器框架的核心，现在被苹果、谷歌、微软等几乎所有科技公司使用：Clang（C/C++/Obj-C前端）、rustc（Rust前端）、Swift编译器都会把源代码转换成LLVM IR，然后交给LLVM后端生成对应架构的机器码。

我们可以看一个最简单的C函数的LLVM IR示例，它和x86、ARM的汇编完全不同，但可以被任何架构的后端识别： ```llvm ; 函数功能：计算两个整数的和 ; 源代码: int add(int a, int b) { return a + b; } define i32 @add(i32 %a, i32 %b) { entry: %sum = add i32 %a, %b ; 对应源代码中的a + b ret i32 %sum ; 返回sum } ``` IR的价值不仅是跨平台，还允许编译器在中间端做大量的通用优化，这些优化不需要关心前端是什么语言，也不需要关心后端是什么架构，只需要操作IR即可。比如你写C代码和Rust代码写的循环，优化逻辑是完全一样的，只需要在IR层面做一次优化，就能同时给C和Rust带来性能提升。

1.2.3 后端：把通用指令变成CPU能听懂的机器码

后端是编译器最“懂硬件”的部分，它的核心任务是把优化后的IR转换成特定CPU架构能执行的机器码，同时针对硬件特性做最后的优化。后端通常分为四个步骤：

1. 指令选择（Instruction Selection）：把IR中的通用指令转换成目标架构的特定指令。比如IR里的加法指令，在x86架构下对应`ADD`指令，在ARM架构下也对应`ADD`指令，但操作码的二进制格式完全不同；再比如IR里的除法指令，在x86下可能对应`DIV`指令，在ARM下可能对应`SDIV`指令，后端需要根据目标架构选择正确的指令。 2. 寄存器分配（Register Allocation）：CPU的通用寄存器数量非常有限，比如x86-64架构只有16个通用寄存器，但你的代码可能有几十个变量需要存储。寄存器分配器的工作就是决定哪些变量放在寄存器里，哪些变量溢出（Spill）到内存里，尽可能减少内存访问的次数，提升执行速度。 3. 优化（Optimization）：后端还会针对硬件特性做架构相关的优化，比如循环展开、指令重排、缓存优化等。比如下面的C循环： ```c for (int i = 0; i < 100; i++) { sum += i; } ``` 开启`-O2`优化后，GCC会把它展开成： ```c for (int i = 0; i < 100; i += 4) { sum += i; sum += i+1; sum += i+2; sum += i+3; } ``` 这样每轮循环只需要做一次判断，而不是四次，性能能提升20%以上。 4. 机器码生成（Code Generation）：最后把优化后的指令转换成目标架构的二进制机器码，输出成目标文件（Object File）。

> 📌 扩展阅读：寄存器分配是编译原理里最经典的NP难问题之一，最经典的解决方案是图着色算法（Graph Coloring），你会在第9章里学到它的具体实现逻辑。

---

1.3 从“Hello World”看编译器的完整魔法

理论讲这么多，不如直接看一个最简单的“Hello World”程序的完整编译流程，你会直观感受到编译器到底做了什么。我们以最经典的C语言Hello World为例： ```c // hello.c #include <stdio.h> int main() { printf("Hello, World!\n"); return 0; } ```

1.3.1 编译全流程拆解

我们用GCC编译器编译这段代码，执行`gcc hello.c -o hello`，背后其实经历了四个核心步骤：

步骤1：预处理（Preprocessing）

预处理器的核心工作是处理所有以`#`开头的预处理指令，比如展开头文件、替换宏、删除注释。上面的代码经过预处理后会变成： ```c // 预处理后的hello.c，stdio.h的内容被展开到这里 int main() { printf("Hello, World!\n"); return 0; } ``` 你可以执行`gcc -E hello.c`直接看到预处理后的结果。

步骤2：编译（Compilation）

这是编译器核心模块工作的阶段，会依次完成词法分析→语法分析→语义分析→IR生成→IR优化→机器码生成，最终输出汇编代码。你可以执行`gcc -S hello.c`得到汇编文件`hello.s`，里面是x86-64架构的汇编代码： ```asm .file "hello.c" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 leaq .LC0(%rip), %rdi call printf@PLT movl $0, %eax popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc ``` 这些汇编代码就是CPU能直接识别的低级指令，但还无法独立执行，因为`printf`函数的实

``` call printf@PLT ``` 这里的`@PLT`是过程链接表（Procedure Linkage Table）的缩写，它是动态链接机制的核心组件——因为`printf`函数并不在我们的源代码里，而是存放在系统的C标准库（glibc）中，编译器在生成汇编代码时