手写MiniJava编译器：编译原理课程设计从词法分析到三地址码全攻略

第一次翻开《编译原理》的时候，我心里其实挺抵触的：“我又不造编程语言，学这个干嘛？”直到自己做编译原理课程设计，才发现这门课和操作系统、计算机网络一样，属于那种“听起来抽象、做起来真香”的硬核内容。哪怕以后不写编译器，词法分析、语法分析、符号表这些概念，本质上是在教你怎么理解“程序是如何被计算机慢慢看懂的”。这篇内容，我就拿自己做的一个MiniJava子集编译器当主线，把从选题、文法设计、词法分析、符号表、语法分析到语义检查和中间代码生成的完整过程拆开讲一遍。内容不会太玄乎，但每一步我都会说清楚“为什么这么设计”和“哪些地方最容易翻车”，适合正在准备编译原理课程设计的同学，也适合想借课程设计把编译原理彻底搞懂的零基础读者。

我见过太多人做编译原理课程设计，最后都变成了“抄一段词法分析代码、复制一段LR分析表”，答辩时一问三不知。我不希望你也走这条路。下面这套路线，不保证让你成为编译器大师，但至少能让你在写完之后，真的敢说一句“语法分析器是我自己推理出来的”。

1. 课程设计选题：决定你是“抄完”还是“学会”的那一步

1.1 为什么很多人把编译原理课程设计做成了“记忆复现”

编译原理这门课的教材跨度非常大，从正则表达式、有限自动机，到LL(1)、LR(1)，再到语法制导翻译和中间代码优化，每一章单独拿出来都能开一门课。课程设计往往只有两三周时间，于是大部分同学的第一个念头是：找个现成的编译器源码，或者直接上一套lex+yacc脚本，跑通一个Demo就算交差。

问题在于，自动生成工具其实是“反学习”的。你用flex生成一个词法分析器，只学会了写规则文件；你用bison生成一个语法分析器，只学会了写产生式。真正让你理解“递归下降”“符号表作用域”“错误恢复”这些核心思想的，反而是手工实现的过程。我记得我们班当时有个同学特别自信，选了个C语言子集的题目，上来就用工具链生成解析器，结果一遇到“变量声明前使用”“函数作用域嵌套”这种需要语义分析配合的场景，整条工具链直接断掉，最后熬夜手动改了三天生成代码，比手写还累。

1.2 三种常见选题方向：先判断你想要的难度梯度

根据我做课程设计辅导和看同学项目的经验，编译原理课程设计基本可以归成三个难度档：

我特别不建议一上来就挑战带面向对象继承特性、泛型、闭包的题目。编译原理课程设计的容量有限，你写得越多，越容易在某个模块卡死。相比之下，一个“变量声明 + 赋值 + 算术逻辑表达式 + if/while + 函数调用 + 基础类型”的静态语言子集，已经足够覆盖90%的考点，而且能让你把符号表和类型检查这两个核心模块吃透。

1.3 我的选题思路：做一个“能跑通类C程序”的教学编译器

我最后选的题目是“MiniJava语言编译器”。MiniJava是很多高校编译原理课程设计的经典选题，它去掉了很多Java里的语法糖，保留类、方法、变量、基本类型和控制流。选择它的原因很实际：Java和MiniJava同源，课堂里大家都会一点Java，写代码样例和验证输出都方便；同时它又是静态强类型语言，做类型检查时不会像C语言那样被隐式转换搞得焦头烂额。

严格来说，我的实现并没有完全编译成目标机器码，而是停在中间代码（三地址码）阶段，然后用一个简单的虚拟机解释执行。这块我后面会细讲。这里想提一个核心观点：课程设计不是做产品，你要明确“我要用什么交付物来证明我理解了整个编译链路”。我的交付物是一整套能画出来的流水线：源码 -> Token流 -> 语法树 -> 带符号表的语义树 -> 三地址码 -> 解释执行。这条链路就是你答辩时最有力的内容。

2. 文法设计：把自然语言的直觉翻译成机器能懂的规则

2.1 从作文段落的角度理解文法，而不是死背BNF

很多同学第一次看到文法产生式，会觉得这东西和数学公式一样难懂。其实文法没那么神秘，它就是描述“一句话怎么组成”的规则集合。你可以把程序源码想象成一篇中文作文：词法是检查每个字是否写错，语法是检查每个句子是否符合“主谓宾”结构，而文法就是规定“什么样的句子是合格句子”的那套语法书。

我在设计MiniJava文法时，没有直接去抄Java语言规范，而是先从“我想让这个语言能写什么程序”倒推。比如我希望支持：

java复制class Main {
    public static void main(String[] args) {
        int a;
        int b = 2;
        a = b + 3 * 4;
        if (a > 10) {
            System.out.println(a);
        }
    }
}

那么我至少要定义这几条规则：程序由类定义构成；类里有方法声明；方法里有变量声明和语句；语句分赋值、条件、循环、调用等。把这些规则写成EBNF，天然就是一棵树。

2.2 消除左递归和提取左公因子：我在手写解析器前最该想明白的事

如果你打算用递归下降法手写语法分析器，就一定会遇到“左递归”问题。举个例子，如果要描述“加法表达式”，最容易想到的文法是：

code复制expr -> expr + term | term

这个文法从数学上完全正确，但它会让程序陷入无限循环。因为递归下降分析器处理 expr 时，第一步就去调用 expr 本身，根本没法往下走。

我当时第一次写到这里，没意识到问题，调试时一看终端不断打印栈溢出，人都懵了。后来才明白，在递归下降里，处理同一层左递归必须改成循环或者右递归。正确的经典写法是：

code复制expr -> term { (+ term) | (- term) }

这里用花括号表示“零个或多个”，意思是：先吃掉一个 term，再反复检查下一个Token是不是加号或减号，如果是，就继续往后吃。这种写法用的就是消除左递归的思路，但它不是教材里那种复杂的 A -> Aα | β 变换，而是把递归调用改成了迭代循环。

2.3 EBNF比BNF更适合手写递归下降

我在课程设计的前三版文法里用的是标准BNF，写起来很繁琐，表达式优先级一旦嵌套深了，产生式一会儿左递归一会儿右递归，分析器代码跟着一起乱。后来我把文法规范改成EBNF，引入了 {} 重复和 [] 可选，问题立刻清晰了。

比如表达式部分，我的EBNF定义是这样的：

code复制expression   -> logical_or_expression ;
logical_or_expression   -> logical_and_expression { "||" logical_and_expression } ;
logical_and_expression  -> equality_expression { "&&" equality_expression } ;
equality_expression     -> relational_expression { ("==" | "!=") relational_expression } ;
relational_expression   -> additive_expression { ("<" | ">" | "<=" | ">=") additive_expression } ;
additive_expression     -> multiplicative_expression { ("+" | "-") multiplicative_expression } ;
multiplicative_expression -> unary_expression { ("*" | "/") unary_expression } ;

这种自顶向下的优先级分层，其实是把“运算符优先级”翻译成了“谁包含谁”的嵌套。你只要保证高优先级的运算出现在更靠下的产生式里，分析时就会先被更内层的方法处理。所以后来我在给学弟学妹讲的时候常说：EBNF写得好，等于语法分析器已经完成了一半。

3. 词法分析器和符号表：最先动手也最容易低估的工程模块

3.1 手写词法分析器 vs 自动生成工具：课程设计里到底选哪个

词法分析器的作用很简单：把源码字符串拆成Token。比如 int a = 10; 会变成 <关键字 int> <标识符 a> <运算符 => <整数字面量 10> <分号 ;> 这样的Token流。

在课程设计阶段，我强烈建议你手写词法分析器，而不是用flex生成。道理有二。第一，手写的过程非常短，几百行内就能搞定一个支持关键字、标识符、数字、字符串和运算符的Scanner；第二，自动生成的词法分析器会把你和“状态转移”“最长匹配”这两个核心概念隔开，你根本体验不到“为什么关键字需要优先于标识符匹配”这类工程问题。

我自己的词法分析器就是一个大循环加几个辅助函数。核心逻辑大概是：

java复制char current = peek();
if (isDigit(current)) {
    return readNumber();
}
if (isLetter(current) || current == '_') {
    String word = readIdentifierOrKeyword();
    if (keywords.contains(word)) {
        return new Token(TokenType.KEYWORD, word, line, column);
    }
    return new Token(TokenType.IDENTIFIER, word, line, column);
}

这里最容易被忽略的细节有两个。一个是“关键字优先匹配”的顺序：在保留字表里查一下就能解决，但如果你用flex，关键字规则和标识符规则的优先级就是经典踩坑点。另一个是字符位置的记录：line 和 column 必须在读取每个Token时都记录下来，否则后面做错误提示和符号表插入时，根本定位不了源码位置。

3.2 符号表的数据结构设计：哈希表只是起点，作用域栈才是灵魂

“编译原理符号表”这个概念，是很多同学背了又忘的重点。表格面意义是“记录变量名、类型、作用域、声明位置等信息”，但真正动手实现时，你会发现没有你想的那么简单：如果只用一张全局HashMap，内层作用域和外层作用域的同名变量会直接冲突，这显然不符合大多数语言的规则。

我当时的做法是“作用域栈”：一个全局符号表栈，每个作用域是一个独立Map，进入一个花括号代码块时压入一层，出来时弹出一层。查找变量时，从栈顶开始往下找，这样内层变量会遮蔽外层变量，语义上完全正确。核心结构类似这样：

java复制class SymbolTable {
    private List<Map<String, Symbol>> scopes;
    
    public void enterScope() {
        scopes.add(new HashMap<>());
    }
    
    public void exitScope() {
        scopes.remove(scopes.size() - 1);
    }
    
    public void define(String name, Type type, int line, int column) {
        Map<String, Symbol> currentScope = scopes.get(scopes.size() - 1);
        if (currentScope.containsKey(name)) {
            throw new SemanticError("变量重复定义: " + name + "，位置: " + line + ":" + column);
        }
        currentScope.put(name, new Symbol(name, type, line, column));
    }
    
    public Symbol lookup(String name) {
        for (int i = scopes.size() - 1; i >= 0; i--) {
            Symbol sym = scopes.get(i).get(name);
            if (sym != null) return sym;
        }
        return null;
    }
}

在课程设计答辩时，老师特别可能会问：“符号表为什么用栈而不是用一棵树？”我的回答是：栈反映的是程序执行时的词法作用域嵌套关系，和代码块的进入退出天然吻合；虽然语法分析阶段也可以把符号组织成一棵作用域树，但解释执行或语义检查通常是顺序遍历AST的，栈结构插入和查找更自然。

3.3 标识符解析和“未声明变量”的报错：越早暴露越好

词法分析阶段产生的标识符Token，本身不知道它对应的是哪个变量。等到语法分析阶段，遇到一个赋值语句 a = b + 1，才应该去符号表里查 a 和 b 有没有被声明。这个动作叫“标识符解析”或“名字解析”，是语义分析里最重要的一步。

我第一次测试一个明显有错误的程序：

java复制class Main {
    public static void main(String[] args) {
        x = 1;
    }
}

结果我的语法分析器直接报“语法错误，期望expression的开始位置，但遇到identifier x”，说得完全不对。后来才发现，问题不是语法，而是语义：x 压根没声明。如果能把这类问题推迟到语义分析阶段统一检查，错误信息就会友好很多：“变量x未声明，位于第3行”。这也是为什么真正的编译器会分阶段处理，而不是在语法分析里把所有事情都干完。

4. 递归下降语法分析：手写解析器不是背书，而是推理

4.1 为什么课程设计更适合手写递归下降，而不是LR(1)

编译原理课程里，语法分析方法通常讲LL(1)和LR(1)，而且给很多同学留下一种印象：好像递归下降是老古董，LR(1)才是王道。但是一个LR分析表可能几十行状态转换，手写会让人怀疑人生。而且LR(1)生成器一旦出现冲突，冲突信息晦涩得能让你debug一整晚。

手写递归下降的优势是“每个非终结符对应一个方法”，阅读和调试都极其容易。比如我上面的EBNF文法，转换后的代码结构几乎是逐行对应：

java复制private AstNode parseEqualityExpression() {
    AstNode left = parseRelationalExpression();
    while (peek().isOperator(Op.EQ) || peek().isOperator(Op.NEQ)) {
        Token op = next();
        AstNode right = parseRelationalExpression();
        left = new BinaryOpNode(op, left, right);
    }
    return left;
}

你只要能在代码里看到 parseExpression、parseStatement、parseBlock 这种层层调用的关系，就能理解“语法树是怎么建的”。这种可读性对课程设计和答辩展示的价值，远超过运行效率上的零星提升。

4.2 用Java实现表达式优先级解析：从“所有运算符平等”说起

我想先讲个很多初学者都会踩的坑。如果你不设计优先级，直接用一个方法解析整个表达式，那么 a + b * c 会被解析成 (a + b) * c，计算结果自然不对。为了避免这个问题，教科书里通常建议的解法是“优先级爬山法”或者“分级下降法”。

我的MiniJava实现里选择的是分级下降法，也就是把表达式按优先级从低到高拆成好几层。处理一元运算负号、括号、数组访问时，也有一个最底层的基础表达式方法：

java复制private AstNode parsePrimary() {
    if (peek().isToken(TokenType.INTEGER_LITERAL)) {
        return new IntLiteralNode(next().getValue());
    }
    if (peek().isToken(TokenType.IDENTIFIER)) {
        String name = next().getValue();
        if (peek().isToken(TokenType.LPAREN)) {
            return parseFunctionCall(name);
        }
        return new VarRefNode(name);
    }
    if (peek().isToken(TokenType.LPAREN)) {
        next(); // 吃掉左括号
        AstNode expr = parseExpression();
        match(TokenType.RPAREN); // 必须有右括号
        return expr;
    }
    throw new ParseError("无法识别的表达式起始符号", peek());
}

这段代码看起来简单，但里面埋着好几个考点。比如 match(TokenType.RPAREN) 的作用不仅是“吃掉一个右括号”，它同时还告诉你：如果这里缺了右括号，报错信息必须指到这里；如果这里多了一个右括号，则要分情况处理，不能直接把栈弄崩。

4.3 错误恢复策略：别让一个括号错误毁掉整份解析

课程设计的解析器，最容易让同学挫败的一点是“一个小错误引发满屏报错”。我第一版实现里，一旦遇到无法匹配的Token，就直接抛出异常终止整个编译过程。结果测试一个文件时，第一行少写了一个分号，整个文件后面所有真正有意义的错误都看不到了，每次只能改一个错误重新编译，体验极差。

后来我引入了“同步Token”的错误恢复策略。具体做法是：当某个语句或表达式解析失败时，不是马上终止，而是不断丢弃Token，直到遇到一个分号、右花括号或者某个关键字作为恢复点，再继续往下解析。伪代码如下：

java复制private void recoverFromError() {
    while (!peek().isToken(TokenType.EOF)) {
        if (peek().isToken(TokenType.SEMICOLON)) {
            next(); // 跳过同步点
            return;
        }
        if (peek().isToken(TokenType.RBRACE)) {
            return; // 不消费右花括号，交给上层处理
        }
        next();
    }
}

引入错误恢复之后，虽然一个程序仍然可能报出几个“连带错误”，但你已经能在一个测试文件里同时看到多个独立问题的错误信息。这一点在课程设计文档的“错误处理”章节里，是非常加分的亮点。我当时专门写了一个包含十类常见错误的测试用例文件，让老师现场看我的编译器一次性输出多个错误位置和原因，效果比空谈“鲁棒性”强得多。

5. 语义检查与三地址码：让程序从“语法正确”走向“有意义”

5.1 语法树之后还缺什么：类型检查和作用域是语义层的两大支柱

很多人的课程设计走到语法分析就停了，觉得AST都建出来了，后面顶多打印一下树节点就算完成。但真正的编译原理课程设计，如果缺了语义分析，答辩时老师往往只会给你一个及格分，因为你没有体现出“程序不仅要语法正确，还要符合语言规范”这一层理解。

语义分析最重要的一件事是类型检查。比如我相信没人希望 int a = true; 在你的语言里能编译通过。我的语义检查阶段采用了两趟遍历的方案：第一趟遍历所有类和方法声明，把方法签名和类结构提前填进符号表，这样即使某个方法定义在调用之后，也能正确解析；第二趟再逐个方法体内部做类型推导和赋值兼容性检查。

类型检查里最典型的坑是“未知类型”。MiniJava里如果你写：

java复制Cat c;

但整个程序没有任何 class Cat 的定义，那么第一趟遍历时，Cat 应该被加入“未解决类型”列表里，等第二趟或者结束时统一报错。如果不管这个，你会遇到一个尴尬的场景：类名和标识符同名时，符号表里查到了某个东西，但它不是类型名字，你该给什么错误？

5.2 中间代码生成：三种地址码为什么能衔接后续阶段

我的课程设计没有做完整的x86汇编生成，而是把MiniJava翻译成三地址码，再交给一个写好的虚拟机执行。三地址码的典型特点是每条指令最多有三个地址、一个运算符。表达式 a = b + c * 2 翻译出来大概是：

code复制t1 = c * 2
t2 = b + t1
a = t2

为什么选三地址码而不是直接生成机器码？一方面是课程设计精力有限，另一方面，三地址码能把“表达式计算”和“控制流跳转”统一成非常容易解释执行的结构。你在实现 if (x > 0) { ... } else { ... } 时，只要生成几条条件跳转指令和无条件跳转指令，后面解释器就能顺序执行，和跑汇编差不多。

我在设计MiniJava的中间表示时，把指令类型设计成了枚举：

java复制enum Opcode {
    ADD, SUB, MUL, DIV,
    LT, GT, EQ, NEQ, AND, OR, NOT,
    ASSIGN,
    LABEL, GOTO, IF_FALSE_GOTO,
    CALL, RETURN, PARAM
}

如果一个布尔表达式是用来控制 if 的，我不会生成“先算布尔值再判断真假”的冗余指令，而是直接在短路计算的过程中生成跳转指令。这一块如果能实现，答辩时可以专门讲“短路求值”，一听就知道你真的理解控制流。

5.3 怎么聪明地控制项目范围：不碰寄存器分配，也可以把“代码生成”讲清楚

到了课程设计的最后阶段，最大的风险是“什么都想做，什么都没做完”。比如优化、寄存器分配、垃圾回收这些方向，单拎出来都能做半个学期。课程设计只有那么点时间，你要学会做减法。

我的策略是：目标代码只用三地址码和自定义虚拟机解释执行，明确不涉及寄存器分配和指令选择。但为了让交付内容看起来完整，我额外写了三块很容易出彩但成本不高的内容：一是中间码的文本可读输出，能直接看到每行源码对应的中间码；二是错误处理信息包含源码行列号，并且错误类型能分类显示；三是一个很小的“迷你调试器”，可以在解释执行时打印每条指令执行前后的变量表。这三块都属于“看起来工作量很大”但理论难度并不高的补充功能，却能帮你在答辩时把完整工具链讲得很有说服力。

6. 做完MiniJava再看真编译器：课程设计留下的迁移能力

6.1 真编译器也不过是把同一件事拆得更细

很多同学课程设计做完就扔了，觉得“我又不研究编译器”。但实际上，课程设计教给你的思考方式，完全可以迁移到真实语言和真实编译器的理解上。就拿日常开发中Java程序怎么被编译这件事来说：.java 源码先被javac解析成语法树，做注解处理、语义分析、生成字节码，JVM再通过类加载器把字节码加载进来，逐条解释或JIT编译成机器码。

如果把你在MiniJava里写的词法分析器、语法分析器、语义分析器、中间代码生成器，和javac、JVM里的模块一一对应，你会发现它们只是分得更多、做得更细，核心逻辑和你的理解完全一致。这是我想说的第一层迁移：课程设计里搭起来的完整流水线视角，能帮你在任何一门真实语言里，快速定位“编译器是在哪个阶段报错的”。

6.2 Swift编译器的几个阶段：用“上一个项目”的眼光看SIL

我也花过一段时间看Swift的编译流程，因为Swift编译器宣传里经常提到SIL（Swift Intermediate Language，中间语言），这名字乍一听高深，但站在课程设计的角度去理解，它其实就相当于我MiniJava里的“三地址码”，只不过SIL做了更严格的类型约束和所有权检查。

Swift编译前端经历词法分析、语法分析、语义分析之后，会生成AST，再进行类型检查和作用域推理，最终降级到SIL。SIL保留了很多高级信息，比如变量的生命周期、函数调用的所属模块、错误处理路径等，所以它可以在这层做很深入的数据流分析和优化。你可以这么类比：MiniJava课程设计里你手工生成一条 t1 = c * 2，就相当于Swift中的SIL指令帮编译器保存了“这个临时值的类型和来源”；只是SIL指令数量更多、类型系统更严谨。

我当时在看Swift源码的SIL文档时，总有种“豁然开朗”的感觉，因为我已经在MiniJava里亲手产出过中间表示，所以看到 alloc_stack、load、store、br 这些指令不再头大。它们的定位，和我给编译原理设计的 LABEL、GOTO、IF_FALSE_GOTO 是一模一样的，只是多了对栈内存和对象引用生命周期的显式描述。

6.3 在现代语言中回看符号表和类型推导：它比你想象中更常出现

还有第二个迁移点：符号表和类型推导。你在编译器课程里认为这是“编译原理”专属的东西，其实打开任何现代语言的IDE，它几乎每天都在跑。比如你在Java的IDE里写代码时，编辑器能提示 cannot find symbol，本质就是IDE内置了一套符号表在后台做名字解析。你在Swift里写了 let value: Int = something，类型检查器会判断右侧表达式是否可以转换成 Int，这也是语义分析那套规则的实时应用。

这也解释了，为什么很多大厂做静态代码分析、做IDE插件、做DSL设计的岗位，招聘信息里都会强调“熟悉编译原理”。编译原理不是一个孤立的知识点，它训练的是“从结构化文本里提取抽象信息”和“在多层抽象之间维护一致性”的能力。课程设计里你亲手维护过的那个作用域栈，在写代码分析工具时几乎可以原封不动地复用。

6.4 关于答辩和资料整理的最后一条经验

虽然这篇更偏实现侧，但既然讲课程设计，答辩材料的整理我不能不提。我见过太多项目本身做得不错、但汇报时东一句西一句的同学。我的经验是准备一张“从源码到执行”的完整数据流图，每一步都对应一个自己能现场演示的例子。老师问“你这个编译器支持作用域吗”，你不要空口说“支持”，而是打开一个嵌套代码块里变量同名遮蔽的测试用例，让老师看符号表和输出结果。老师问“错误恢复是什么”，你用一份故意写错的测试文件现场展示三四个错误同时报出来的效果。

这些演示材料比解释概念有说服力得多。我在最后测试时，甚至专门为每个核心模块准备了一个演示文件，比如 scope_test.minj、type_error_test.minj、short_circuit_test.minj。答辩时所有代码都能在五分钟内跑完，老师一眼就能看出你确实掌握了编译原理的完整流程，不只是在背概念。