简介：这是一套面向计算机专业学生及编译原理初学者的课程实验合集，对应中国海洋大学2020年春季学期编译原理课程，围绕从源程序到目标代码的完整编译流程组织，适合配合课堂学习、课程设计或自测实践使用。压缩包共74个文件、约774KB，以18个C源文件、8个.l词法规则与8个.y语法规则文件为核心，辅以8个头文件、11个可执行程序、7个TXT说明及Makefile等构建脚本，覆盖词法分析、语法分析、语义检查、中间代码生成、代码优化、目标代码生成、错误处理与编译器集成八个实验，并附实验内容和要求文档。已有4419人学习下载。读者可据此理解Flex/Bison等工具的使用方式，查看各阶段组件的实现思路与衔接关系，对照实验要求完成语法树构建、符号表管理、三地址码生成及错误诊断等练习，也能借鉴目录组织和调试方法，为课程实验与编译器构造入门提供较完整的参考。
1. 编译原理实验五关连打：一份能直接跑的实验源码合集值在哪
每学期到词法分析那一周，总有人对着满屏的unexpected token熬到凌晨。编译原理实验的难，不在单个知识点，而在于五个阶段是串联的：词法输出的 token 流错一位，语法分析就会报一堆莫名其妙的错；语法树结构歪了，语义分析的符号表必然崩；符号表一崩，中间代码和目标代码根本无从谈起。这份某高校编译原理课程的实验源码合集，覆盖的正是这条完整链路——词法分析、语法分析、语义分析、中间代码生成、目标代码生成，每一关都是能独立编译运行的工程，配了测试用例和期望输出。适合三类人：赶实验节点想先跑通再理解的在校生、想把课程设计从零重建一遍的自学者、需要一份小而全的前端参照实现来对照自己项目结构的开发者。
2. 五关拆解：从正则到目标代码，每个工程到底在做什么
拿到一个“全部实验”的压缩包，最容易犯的错是从第一个文件夹开始逐个读源码，读完词法就迷失在状态转移表里。正确的顺序是先看清五个工程各自负责的边界：输入是什么形态、输出是什么形态、中间通过什么数据结构交接。这一章按这条链路拆，每段给一个最小可复现的实现片段，你可以直接对着改自己实验里的对应模块。
2.1 词法分析工程：最长匹配、回退和关键字表
词法分析的核心任务是把字符流切成 token 流，听起来简单，真正的考点在两处：一是最长匹配，二是关键字与标识符的区分。很多人第一次写扫描器会用if (c == '<') { if (peek() == '=') return LE; return LT; }这种手写分支，小语言能跑，一旦文法里加上<<=、...、->这类多字符算符，分支树就会爆炸，而且极容易漏掉前缀冲突。
常见做法是用正规式描述每一类 token，走 Thompson 构造出 NFA，再用子集构造法确定化成 DFA，最后把 DFA 存成一张二维转移表。表驱动的好处是逻辑和规则分离：改文法只需要重新生成表，扫描主循环一行都不用动。这份实验包里的词法工程就是表驱动结构，trans[state][char_class]是转移矩阵，accept[state]记录该状态是否终态以及对应的 token 类型。
/* lexer.c —— 最长匹配 + 回退的扫描主循环（节选） */ Token next_token(Scanner *s) { for (;;) { skip_blank_and_comment(s); /* 跳过空白、// 与块注释 */ if (s->pos >= s->len) return make_token(TOK_EOF, s, s->pos); int state = 0; /* DFA 起始状态 */ int last_accept = -1; /* 最近一次到达终态的位置 */ int last_kind = TOK_ERR; while (s->pos < s->len) { int cls = char_class(s->buf[s->pos]); /* 字符归类：字母/数字/界符 */ int next = trans[state][cls]; /* 状态转移表查询 */ if (next < 0) break; /* 进入死状态，立刻停 */ state = next; s->pos++; if (accept[state] != TOK_NONE) { /* 记下这个终态 */ last_accept = s->pos; last_kind = accept[state]; } } if (last_accept < 0) { /* 一个字符都没匹配上 */ s->pos++; /* 吃掉非法字符，防止死循环 */ return make_token(TOK_ERR, s, s->pos); } s->pos = last_accept; /* 关键：回退到最后一个终态 */ Token t = make_token(last_kind, s, s->pos); if (last_kind == TOK_ID && is_keyword(t.lexeme)) t.kind = keyword_code(t.lexeme); /* 标识符降级为关键字 */ return t; } }这段代码里最容易看漏的是last_accept这个变量，它才是最长匹配的落点。举例：输入a<=b，扫描a时终态落在标识符；扫到<时状态继续推进，因为存在<到<=的转移；扫到=后进入<=的终态，此时last_accept更新；再读b时转移表返回死状态，循环退出，pos被拉回到<=之后，而不是b之后。如果没有回退这一步，<和<=会被错误地拆开或者吞掉后面的字符，这是词法实验里最高频的翻车点。
char_class是一层间接映射，把 ASCII 压缩成十几个字符类（字母、数字、下划线、运算符、分隔符、非法字符），表的大小从状态数 × 128 降到状态数 × 16，这也是教科书里建议的做法。关键字识别放在扫描之后做一次哈希查表，比把 30 多个关键字全部编进 DFA 要省几十个状态。
2.2 语法分析工程：递归下降和 LR 表驱动各自适合什么文法
语法分析这一关，实验包通常会给两套实现：递归下降和 LR 表驱动。别急着选“看起来高级的那个”，先看你的文法。递归下降要求文法无左递归、无公共左因子，写起来直观、报错信息好做、调试可以直接打断点顺着调用栈看；缺点是改文法就得改代码，文法一复杂函数就散。LR 表驱动则相反，改文法只需要重算分析表，代码逻辑永远是一个shift / reduce / accept的循环。
判断标准很朴素：如果你的文法要支持if-else、while、函数调用、表达式优先级，且后面还有语义分析和代码生成要接，选 LR 表驱动更省事，因为归约动作天然对应语法树节点的构造时机。如果是教学实验只要求识别语句结构，递归下降半小时能写完。
/* parser.c —— SLR/LR(1) 表驱动的移进-归约主循环 */ int parse(SymStack *st, TokenStream *ts) { push_state(st, 0); Token look = peek(ts); for (;;) { int s = top_state(st); Action a = action_table[s][look.kind]; if (a.type == ACT_SHIFT) { push_state(st, a.target); push_sym(st, make_terminal(look)); /* 终结符也入符号栈，供建树 */ advance(ts); look = peek(ts); } else if (a.type == ACT_REDUCE) { Production *p = &grammar[a.target]; Node *n = new_node(p->lhs); /* 归约即建树，时机最关键 */ for (int i = 0; i < p->rhs_len; i++) { pop_state(st); Node *child = pop_sym(st); prepend_child(n, child); /* 逆序挂载，最后反转 */ } reverse_children(n); int g = top_state(st); push_sym(st, n); /* 非终结符入栈 */ push_state(st, goto_table[g][p->lhs]); } else if (a.type == ACT_ACCEPT) { return 0; } else { report_error(s, look, action_table[s]); /* 报错要带上状态号和期望集合 */ return -1; } } }三个参数值得展开讲。action_table[state][token_kind]是分析表，单元格里存SHIFT target、REDUCE production_id或ACCEPT，构造方式通常用 FIRST/FOLLOW 集算 SLR，想更严谨就上 LR(1) 项目集族；goto_table[state][nonterminal]是归约后的转移表，和 action 表分开放，因为查表键的类型不同。prepend_child之后再reverse_children，是因为归约时符号栈是逆序弹出的，直接挂上去子节点顺序会反，这个细节在打印语法树时一眼就能看出来——a - b会变成b - a。
报错信息里带上state和期望 token 集合，是这份实验包里比较实用的设计。LR 分析器出错时只知道“当前状态 + 当前 lookahead 没有动作”，不给期望集合的话，你根本不知道是文法写错了还是输入写错了，只能对着分析表一行行数。
2.3 语义分析工程：作用域链上的符号表怎么建
语法树建起来之后，语义分析要做三件事：建符号表、做类型检查、标注每个标识符的绑定信息。符号表的数据结构选择直接决定后面几步好不好写。用单张全局哈希表是最省事的，但一旦语言支持块作用域（{ int x; } { int x; }），就必须处理同名遮蔽，这时候要么在表项里存作用域深度做版本淘汰，要么用作用域链。
实验包里用的是作用域链：每个Scope持有自己的哈希桶和指向外层的parent指针，进入{}时压一层，离开时弹一层。查找由内向外逐层走，命中的第一层就是正确绑定，天然实现了遮蔽语义。这个结构对后面生成中间代码也友好，因为可以直接把Symbol*指针挂到 AST 的标识符节点上，代码生成阶段不用再查一次表。
/* symtab.c —— 作用域链式符号表 */ void enter_scope(SymTab *t) { Scope *sc = calloc(1, sizeof(Scope)); sc->parent = t->cur; /* 指向外层作用域，形成链 */ sc->depth = t->cur ? t->cur->depth + 1 : 0; t->cur = sc; } void exit_scope(SymTab *t) { Scope *sc = t->cur; t->cur = sc->parent; /* 只弹指针，桶里的 Symbol 留给后续阶段引用 */ sc->detached = 1; } Symbol *lookup(SymTab *t, const char *name) { for (Scope *sc = t->cur; sc; sc = sc->parent) { /* 由内向外逐层找 */ Symbol *s = hash_get(&sc->bucket, name); if (s) return s; } return NULL; } int insert(SymTab *t, Symbol *s) { if (hash_get(&t->cur->bucket, s->name)) return -1; /* 同层重定义，报错 */ s->scope = t->cur; hash_put(&t->cur->bucket, s); return 0; }exit_scope里只弹指针、不释放Symbol，这个设计是有意的：AST 节点上挂着Symbol*，如果在退栈时把内存释放掉，代码生成阶段访问就是野指针。代价是内存占用略大，但课程实验的规模完全无所谓。insert只检查当前层是否重定义，不检查外层，这是“同名遮蔽”和“重复定义”的分界线——很多人在这里写错，导致内层变量定义被误判成重复定义。
类型检查一般用一遍后序遍历就能做完：表达式节点自底向上算类型，语句节点检查条件表达式是否为布尔、赋值左右类型是否兼容、函数调用实参个数和类型是否匹配。检查失败不要直接exit(1)，收集到一个错误列表里统一输出，否则一次只能修一个错，来回跑几十遍。
2.4 中间代码与目标代码工程：四元式、回填和寄存器分配的最小实现
中间代码这一关，实验包的输出是四元式(op, arg1, arg2, result)。四元式的好处是可读、可 dump、便于和期望输出逐行比对，比三地址码的字符串形式好做回归测试。真正卡人的不是四元式本身，而是布尔表达式的短路求值和控制流的回填。
考虑if (a < b || c > d) S1; else S2;。||是短路的，a < b为真时c > d根本不该执行，所以你不能先算完整个条件再跳转，必须边生成边留下待填的跳转目标。标准解法是给每个布尔表达式维护两张链表：真出口链和假出口链，先生成目标位置未知的跳转，等目标确定后再统一回填。
/* quad.c —— 短路求值的条件跳转与回填 */ int emit_cond_jump(const char *cond) { Quad *q = &quads[nq]; q->op = "jnz"; /* 条件为真则跳 */ q->arg1 = cond; q->result = -1; /* -1 是占位符，表示目标待回填 */ return nq++; } void backpatch(IntList *l, int target) { for (IntList *p = l; p; p = p->next) { if (quads[p->id].result == -1) quads[p->id].result = target; /* 把占位符替换成真实四元式下标 */ } free_list(l); } /* E -> E1 || M E2 的语义动作： M: mark = nq; 记录 E2 代码入口 E.true_list = merge(E1.true_list, E2.true_list); E.false_list = E2.false_list; backpatch(E1.false_list, M.mark); E1 为假才继续算 E2 */backpatch里做result == -1的判断，是为了防止同一条四元式被两张链表重复回填。短路求值里真链假链会交叉合并，如果不加这个保护，第二次回填会覆盖第一次的结果，症状是跳转目标莫名其妙指向中间某条指令，程序跑起来不报错但结果全错，这种 bug 用打印调试很难定位。
目标代码生成部分，实验包给的是朴素的寄存器分配：表达式求值时维护一个寄存器池，算完子树就释放临时寄存器，赋值语句的结果落到变量对应的栈槽或者直接写回内存。这个策略不最优但足够通过实验，因为寄存器分配的最优解（图着色）在课程实验的规模下根本用不上。真要往下做，可以加一步活跃变量分析，把相邻指令里不再使用的变量寄存器提前释放——这就是第 6 章要讲的进阶验证点。
3. 跑通实验环境：从解压到第一个用例通过
源码拿到手，最大的浪费是花两小时配环境、五小时修编译错误，最后发现自己根本没开始读逻辑。这一章按“先跑通、再理解”的顺序给一套固定动作，目标是二十分钟内让第一个测试用例出正确输出。
3.1 目录结构：源码、样例、脚本三块要分清
解压后先别急着make，用tree -L 2看一眼整体布局。这类实验合集的组织方式高度相似，基本是三块：每个实验一个源码目录、一个tests/放输入和期望输出、一个scripts/放批量运行脚本。
| 目录 | 内容 | 使用方式 |
|---|---|---|
lexer/parser/semantic/icode/codegen/ | 五个阶段各自的源码与 Makefile | 单独构建，单独运行 |
tests/<stage>/case_*/ | input.txt输入与expected.txt期望输出 | 逐用例比对 |
scripts/run_all.sh | 批量跑全部用例并汇总 diff | 全量回归时用 |
common/ | Token 定义、AST 节点、错误码等共享头文件 | 五个工程共同包含 |
docs/ | 文法定义、四元式格式说明、实验要求 | 改代码前必读 |
common/和docs/是最容易被跳过、也最不该跳过的两个。前者决定了五个工程之间的接口是否一致，后者里的文法定义是你改任何逻辑的前提——不看清产生式就动语法分析，等于闭着眼睛改代码。
3.2 统一构建：一次make让五个工程全部可执行
每个子目录都有独立 Makefile，但参数最好统一。常见做法是在根目录放一个总 Makefile，用-C逐个进入子目录构建，构建产物统一落到build/下，避免每个目录里散落一堆.o文件。
# 根目录构建：五个工程一次编完，产物集中在 build/ make -j4 stage=all # stage 可取 lexer/parser/semantic/icode/codegen/all # 只编词法，并打开调试符号和告警 make -C lexer CFLAGS="-g -O0 -Wall -Wextra" -j4 # 清理（不删 build 目录下的样例输出，只清中间文件） make clean stage=all参数说明：stage是自定义变量，在 Makefile 里用条件分支决定SUBDIRS的取值；CFLAGS覆盖默认编译选项，-g -O0是为了用 gdb 单步时变量不被优化掉，-Wall -Wextra能提前揪出一批未初始化变量和符号比较问题——这类实验代码里int和size_t混比是常态，不开告警很容易在边界用例上翻车。-j4按机器核数调整，五个工程互相独立，并行编译没有依赖问题。
如果编译报undefined reference to hash_get这类链接错误，八成是common/里的实现没有一起编进去。检查 Makefile 里的SRCS是否包含../common/symtab.c，很多实验包的子目录 Makefile 默认只编当前目录的.c。
3.3 用回归脚本验证：单用例比对和全量 diff
单个用例跑通不算数，要跑全量。实验包里的run_all.sh通常是一个循环，逐个用例执行、diff 期望输出，最后统计通过率。如果脚本缺失或者写得太糙，自己写一个十行的版本更省事。
#!/usr/bin/env bash # scripts/run_all.sh —— 全量回归：逐用例执行并 diff 期望输出 set -u STAGE=${1:-lexer} BIN="build/${STAGE}" PASS=0; FAIL=0; FAILED_CASES=() for d in tests/"${STAGE}"/case_*/; do name=$(basename "$d") actual=$("$BIN" < "$d/input.txt" 2>&1) if diff -q <(echo "$actual") "$d/expected.txt" >/dev/null; then PASS=$((PASS+1)) else FAIL=$((FAIL+1)); FAILED_CASES+=("$name") echo "=== FAIL: $name ===" diff <(echo "$actual") "$d/expected.txt" | head -20 fi done echo "pass=$PASS fail=$FAIL" [ "$FAIL" -eq 0 ] || printf 'failed: %s\n' "${FAILED_CASES[*]}"几个细节值得说。2>&1把标准错误也收进实际输出，因为很多实验的错误信息走 stderr，不重定向的话 diff 永远显示“期望有输出、实际为空”。head -20限制 diff 行数，语法树或者四元式一旦整体错位，diff 会刷出几百行，看前 20 行足够定位第一个分歧点。FAILED_CASES数组把失败用例攒起来最后统一打印，比滚动屏里翻找高效得多。
跑完全量之后，通过率是 60% 还是 95% 并不重要，重要的是第一个失败用例。按文件名排序的第一个失败点，往往就是最上游的 bug——词法错了，后面四个阶段的用例会成片失败，别被总数吓到。
4. 阶段间接口：Token、AST、四元式怎么传才不出错
五个工程能各自跑通，不代表串起来能跑通。串联失败的原因几乎都出在接口上：上一个阶段输出的结构，下一个阶段按错误的字段解读。这一章把三个关键数据结构的字段语义和调试手段讲清楚，这部分内容比算法本身更影响你改代码的效率。
4.1 Token 结构体：行列号、字面量和类型码一个都不能少
Token 是最容易被写“瘦”的结构。很多人只存kind和lexeme两个字段，跑到语义分析报错时想打印“第几行第几列出错”，发现根本没有行列号，只能回头改词法、改所有构造点、重新编译五个工程。这个返工成本极高，一开始就把字段补全。
/* token.h —— 词法单元定义 */ typedef enum { TOK_EOF = 0, TOK_ERR, TOK_ID, TOK_INT, TOK_FLOAT, TOK_STRING, /* 关键字 */ TOK_IF, TOK_ELSE, TOK_WHILE, TOK_RETURN, /* 运算符与分隔符 */ TOK_PLUS, TOK_MINUS, TOK_STAR, TOK_SLASH, TOK_ASSIGN, TOK_EQ, TOK_NE, TOK_LT, TOK_LE, TOK_LPAREN, TOK_RPAREN, TOK_LBRACE, TOK_RBRACE, TOK_SEMI, TOK_COMMA, TOK_KIND_MAX } TokenKind; typedef struct { TokenKind kind; /* 类型码，语法分析查表的键 */ char *lexeme; /* 原始字串，报错和建符号表时用 */ int line; /* 起始行号，从 1 开始 */ int col; /* 起始列号，从 1 开始 */ union { /* 已解析的字面量值，省去下游重复 atoi */ long ival; double dval; char *sval; } lit; } Token;kind是语法分析查 action 表的键，必须连续且从 0 开始，中间不要留空洞，否则分析表会浪费一堆列。lexeme指向源缓冲区还是单独strdup，取决于你的内存策略：指向缓冲区最快但生命周期绑死输入，strdup安全但要记得释放，实验规模下建议后者，省心。
lit这个联合体是加分项。词法阶段顺手把整数字面量转成long、浮点转成double，语义分析的常量折叠和代码生成的立即数直接用，不用在下游再写一遍strtol，也避免了"0123"这种八进制歧义在下游被误解析。
4.2 AST 节点：判别式加联合体，还是继承层次
语法树的结构选择，取决于你用的语言。C 里没有继承，标准做法是判别式（tagged union）：一个kind字段标明节点类型，一个union存该类节点特有的字段，公共字段（行号、子节点数组）放在外层。C++ 或 Java 可以用继承加访问者模式，扩展新节点类型时不用改 dump 函数。
/* ast.h —— 判别式 + 联合体的 AST 节点 */ typedef enum { ND_NUM, ND_VAR, ND_BINOP, ND_ASSIGN, ND_IF, ND_WHILE, ND_CALL, ND_BLOCK } NodeKind; typedef struct Node Node; struct Node { NodeKind kind; int line; /* 从 Token 继承，报错定位用 */ Node **kids; /* 子节点数组，顺序即语法顺序 */ int nkids; union { struct { long ival; } num; struct { char *name; struct Symbol *sym; } var; /* sym 由语义分析回填 */ struct { int op; Node *lhs, *rhs; } bin; /* op 用 TokenKind */ struct { Node *cond, *then_s, *else_s; } iff; struct { Node *cond, *body; } whil; struct { char *name; Node **args; int nargs; } call; } u; };kid用数组而不是left/right两个指针，是为了让ND_BLOCK、ND_CALL这类变长子节点也能统一处理。二叉树用数组只浪费一点空间，但 dump、遍历、释放的代码可以只写一份。
var里的sym字段是关键设计：语法分析阶段它是NULL，语义分析查到符号后回填指针。代码生成阶段直接读node->u.var.sym->slot拿栈偏移，不需要再走一次作用域链查找。这种“语义分析回填指针”的模式在真实编译器里很常见，比在每个阶段重复查表干净得多。
4.3 每阶段加 dump 开关：把中间结果落成黄金文件
调试编译器前端最有效的手段不是断点，是 dump。给每个阶段加一个--dump-ast、--dump-quad的命令行开关，把中间结果按固定格式打到 stdout 或者文件，然后和手工构造的期望输出 diff。这套做法在实验里的价值远高于任何调试技巧：它把“程序行为对不对”变成了“文本比不比对得上”，可重复、可回归、可提交给同学对照。
/* dump.c —— 缩进式 AST 打印，格式固定便于 diff */ void dump_node(Node *n, int depth) { if (!n) return; for (int i = 0; i < depth; i++) fputs(" ", stdout); switch (n->kind) { case ND_NUM: printf("NUM %ld\n", n->u.num.ival); break; case ND_VAR: printf("VAR %s%s\n", n->u.var.name, n->u.var.sym ? " [bound]" : " [unbound]"); break; case ND_BINOP: printf("BINOP op=%d\n", n->u.bin.op); break; case ND_IF: printf("IF\n"); break; case ND_WHILE: printf("WHILE\n"); break; case ND_CALL: printf("CALL %s argc=%d\n", n->u.call.name, n->u.call.nargs); break; case ND_BLOCK: printf("BLOCK n=%d\n", n->nkids); break; default: printf("NODE kind=%d\n", n->kind); break; } for (int i = 0; i < n->nkids; i++) dump_node(n->kids[i], depth + 1); }格式设计有两个原则：一是每行一个节点，不要在一行里打整个子树，否则 diff 一行不同会导致整行重排，看不出真正改了哪个节点；二是把关键判定显式打出来，比如[bound]/[unbound]直接告诉你语义分析有没有正确回填符号指针，比在 gdb 里追指针快十倍。缩进用两个空格而不是制表符，是防止不同编辑器展开宽度不一致导致 diff 全红。
四元式的 dump 同理，一行一条，格式固定成序号: (op, arg1, arg2, result)，-1的占位目标原样打出来。回填前后各 dump 一次，两张表并排看，就能立刻确认哪些跳转目标没被填上。
5. 避坑与排查：五个反复出现的翻车现场
这些坑不分水平高低，写十遍编译器前端也还是会踩。按“现象 → 原因 → 解决”整理，遇到问题时对着症状找，比通读代码快得多。
5.1 词法把==拆成两个=，报错满屏
现象：词法输出里本该是一个TOK_EQ的地方出现两个TOK_ASSIGN，语法分析立刻在if (a == b)上报“期望表达式，遇到 =”。
原因：扫描主循环没有回退，或者转移表里<、=、!只有单字符终态，没有到双字符终态的转移。另一种情况是回退了但没更新last_kind，导致回退位置对、类型错。
解决：在扫到终态时同时记录last_accept位置和last_kind，循环退出后把pos拉回last_accept，用last_kind构造 token。构建一张最短的验证用例表：= == < <= << >> ->，逐个跑，一个都不能错。
5.2 语法分析报移进/归约冲突，if-else配对错位
现象：悬空 else 问题——if (a) if (b) s1; else s2;里的else被错误地绑到外层if。也能表现为分析表构造时报大量冲突，程序直接退出。
原因：文法有歧义，没有定义运算符优先级和结合性，或者定义顺序不对。LR 分析器默认“移进优先”，这恰好能解悬空 else，但如果优先级表没写，表达式的a+b*c会被算成(a+b)*c。
解决：显式写一张优先级表，从低到高排列||、&&、==、!=、<、<=、+、-、*、/，并标明左结合。冲突数量应该从几十个降到零或者个位数，剩下的如果是悬空 else，确认选择移进即可。
5.3 语义分析查不到变量，明明声明在上面
现象：lookup返回NULL，报“未声明的标识符”，但你翻源码确认变量就在前几行。
原因：三种可能——一是exit_scope调用时机错了，在处理完{}之前就把作用域弹了；二是insert只在当前作用域查重，但外层同名变量遮蔽了内层，lookup从内向外找到了内层的，逻辑没错但类型不同；三是声明语句的遍历顺序排在引用之后，后序遍历没写对。
解决：在enter_scope/exit_scope/insert/lookup里各打一条带depth的日志，跑一个最小用例{ int x; { int x; x = 1; } }，看日志里的深度变化是否符合预期。遮蔽是正常语义，不是 bug；真正要修的是弹栈时机。
5.4 四元式里跳转目标全是-1，回填没生效
现象：dump出来的四元式表里，所有jnz的result都是-1，执行时跳到非法地址或者直接崩。
原因：回填列表被合并时丢失了，或者backpatch调用在了emit之前。更隐蔽的一种是merge函数返回新链表，但调用方忘了用返回值，原地链表的节点被漏掉。
解决：backpatch里加断言，把目标小于当前四元式下标的回填直接打日志报警——往已经生成的指令跳转，基本可以确定是列表里混进了不该有的下标。合并链表用merge(a, b)返回新头，所有调用点统一写l = merge(l1, l2)，不要写原地修改版本。
5.5 目标代码寄存器被覆盖，结果错但不崩溃
现象：简单表达式结果对，稍微嵌套几层（a = b + c * d - e）就错，且错误结果看起来像某个中间值被用了两次。
原因：寄存器池分配时没有记录使用状态，两个子表达式拿到了同一个物理寄存器；或者释放时机过早，父节点还在用的时候子节点算完就把寄存器还了。
解决：寄存器池改成显式的位图加引用计数，分配时置位、释放时清位，释放前断言引用计数归零。调试时在每条指令生成后打印寄存器分配状态，能一眼看出哪个寄存器被复用了。再往下走就是活跃变量分析的范畴，实验阶段先用位图把正确性锁住。
提示：这五条里有四条都能靠“每个阶段 dump 中间结果 + 最小用例”定位，工具先于技巧。
6. 进阶验证：差分测试和 GCC 对照，把“感觉对”变成“证明对”
实验通过的标准是期望输出对得上，但期望输出本身可能是错的，或者只覆盖了正常路径。我带过的一次课程设计里，五个人五套实现，各自的样例都过，凑到一起跑综合用例才发现三套在嵌套注释上行为不一致。从那以后我习惯做一层额外验证：差分测试。
具体做法是把递归下降和 LR 表驱动两套语法分析各跑一遍同一批输入，把生成的 AST dump 到文件里做 diff。这两套实现的算法完全不同，同时出错在同一处的概率极低，diff 一旦非空，基本能锁定是用例触发了某个边界。实验包里正好两套都给，这个验证几乎是零成本的。
# 差分测试：两套解析器跑同一批输入，比对 AST dump for f in tests/parser/case_*/input.txt; do build/parser_rd --dump-ast < "$f" > /tmp/rd.ast 2>&1 build/parser_lr --dump-ast < "$f" > /tmp/lr.ast 2>&1 if ! diff -q /tmp/rd.ast /tmp/lr.ast >/dev/null; then echo "DIVERGE: $f" diff /tmp/rd.ast /tmp/lr.ast | head -10 fi done第二层验证是拿真实编译器当标杆。把你实现的语言子集翻译成 C 片段，分别用自家代码生成器和gcc -O0编译运行，比对标准输出。这一步能抓住中间代码里的语义错误，比如短路求值写反、整数除法向零截断的符号问题、前置自增和后置自增的求值时机。这类错误在自己写的解释器里往往看不出来，因为解释器的求值顺序是你自己定的。
| 验证手段 | 输出物 | 能抓什么问题 | 成本 |
|---|---|---|---|
| 黄金文件回归 | 各阶段 dump 与期望 diff | 功能回归、改代码引入的新错 | 低，脚本一次写好 |
| 双实现差分 | 两套 parser 的 AST diff | 边界用例、文法歧义处理差异 | 低，实验包自带两套 |
| 对照真实编译器 | 标准输出比对 | 语义细节、求值顺序、类型转换 | 中，要写翻译胶水 |
| 随机表达式生成 | 批量用例与通过率 | 覆盖率盲区、深层嵌套崩溃 | 中，生成器要控递归深度 |
第三层是我个人最推荐的：写个五十行的随机表达式生成器，随机产生带括号、带优先级、带一元负号的算术表达式，同时用自家编译器和宿主语言求值，比对结果。跑一万条，能崩出你手工构造用例永远碰不到的栈溢出和优先级漏洞。生成器要注意控制递归深度，不然第一次跑就会因为自己栈溢出而误判成被测程序的 bug。
一个具体的小技巧：把随机生成器的种子固定下来写进测试脚本注释里。出问题时能精确复现那一条用例，不然一万条里挑一条，光找就得半天。我现在每次接手新的前端实现，第一件事就是把这套差分脚本挂上去跑一遍，先量出基线通过率，再动代码——没有基线的优化，改坏了都不知道。希望帮到你。
本文还有配套的精品资源，点击获取
