每次看到有同学抱着“本机都跑过了为什么OJ不给我过”的委屈来找我，我都会想起自己当年在这批标号为F到M的编译原理实验上熬过的几个通宵。说实话，编译原理实验放在OJ平台上做，本身就是一件很刺激的事情：你写的是一个能“读代码的程序”，而OJ只用一个冰冷的判定结果来回应你的全部努力——WA、RE、TLE，连个用例都不给你看。如果你正在被这批实验折磨，或者马上要开始做，这篇总结应该能帮你少踩几个我当年踩过的坑。

这篇文章围绕的就是“学校OJ上的编译原理系列实验（F到M）”这条完整的实践链路。它不是一个孤立的小作业，而是一组循序渐进的实验：从词法分析开始，一路做到语法分析、中间代码生成，每一环都在为下一步铺路。适合正在做课设的在校生，也适合工作后想回头补一补编译器基础的同学。我会把每个阶段最容易出问题的地方、为什么要这样设计、以及实际排查思路都掰开揉碎讲清楚。

1. 为什么OJ上的编译原理实验总在偷偷加难度

想通过这批实验，第一件事不是写代码，而是搞清楚OJ和你平时写IDE里的程序到底有什么不一样。编译原理实验在这方面的“信息差”特别大，很多同学挂得不冤，但也确实可惜。

1.1 本地能跑和OJ接受是两码事

OJ的判题逻辑是一个纯粹的黑盒：它用一组你没见过的输入跑你的程序，然后严格比对输出。这个过程中没有调试器，没有中间日志，你唯一能看到的就是一个判定结果。

对于普通算法题，黑盒影响还不算大——毕竟输入是数字，输出是数字。但编译原理实验的输入是“程序源码文本”，这就麻烦多了。OJ构造测试用例时，会专门塞给你那些你在本地根本不会打出来的输入：

• 行尾有的是\n，有的是\r\n，还有的文件最后一行根本没有换行符；
• 标识符可以很长，长到你初始化的数组装不下；
• 注释里可能嵌套注释，字符串里可能包含转义引号；
• 源码里可能有多余的空白行、连续空格、Tab键，甚至全角和半角混着来。

你本地测试时，输入的代码是自己手打的，格式干净、长度适中、没有奇奇怪怪的边界。而OJ的测试点是专门来试探你程序鲁棒性的。这就是“本地能跑，一交就挂”的最常见根源。

我在做这类实验时学到的最重要一课是：不要把OJ当成一个会“运行”你程序的地方，把它当成一个会“审问”你程序的考官。你的代码必须在各种畸形输入面前都不崩溃，并且在输出格式上跟标准答案一个字符都不差。

1.2 从F到M这条实验链，是一环扣一环的

这批标号从F到M的实验，表面上看是8个相互独立的题目，实际上是一条完整的编译流水线。

按我自己的理解，F和G大概率对应词法分析相关的内容，再往后是语法分析、语义分析和中间代码。你可能会想：反正每次提交都是独立题目，我每个实验单独写不就行了？想法很好，但现实很骨感——后一个实验的输入格式，往往就是前一个实验的输出格式。举个例子：语法分析实验给你的输入，通常是已经被词法分析器切分好的token序列，而不是原始源码文本。如果你在前一个实验里输出的token类型、属性值、位置信息跟OJ期望的格式不一致，等到做下一个实验时，你的整个实现就接不上了。

更现实的问题是：很多同学做F实验时图省事，把词法分析器写成一个一次性函数，读完一个文件就结束，token也不保存，直接边读边分析。这样F实验或许能过，但到了语法分析实验，你发现你需要的是“能够反复取用、随时回溯”的token流，就得把整个词法分析重写一遍。

我做这批实验的策略是：从第一个实验开始，就把词法分析器设计成一个可复用的组件——输入源码，输出token列表，同时保留每个token的类型、值、行号、列号。后面对接语法分析、符号表、中间代码生成的时候，这个组件几乎没改过。这就是我常跟学弟学妹说的：编译原理实验其实是“围棋”，不是“打地鼠”，每步棋都要想着后面几步。

2. 词法分析：手写状态机才是刷OJ的正解

词法分析是整条链路的地基。这个阶段的理论知识很多：正则表达式、NFA、DFA、子集构造、最小化，听起来一套一套的。但落到OJ实验上，我的建议很直接：别一上来就想搞自动生成器，手写状态机是最稳、最好调试、也最容易过OJ的做法。

2.1 从正则到状态转移表的代码落地

理论课上教的流程是：正则表达式 → NFA → 子集构造法转DFA → 最小化DFA。实际做OJ实验时，你完全可以跳过中间步骤，直接根据语言规则手写一个状态转移表，然后在代码里用一个二维数组驱动它。

比如识别标识符、关键字、整数常量、运算符、分号、括号等等，大致可以设计这样一组状态：起始态、标识符态、数字态、注释态、结束态。核心架构是一个循环：

int state = 0; while (ch != EOF) { int next = transition[state][charClass(ch)]; if (next == -1) { // 当前token结束，根据state确定token类型 emitToken(state, startPos, currentPos); state = 0; } else { state = next; ch = getNextChar(); } }

这里的charClass把一个字符映射到类别（字母、数字、运算符、空白、其他），transition是状态转移表。为什么要用表驱动而不是一堆if-else嵌套？因为表驱动方式下，状态、输入类别、转移结果都是数据，调试的时候把表打出来，一眼就能看出哪个转移配错了。而一团if-else嵌套，一旦出错，你只能顺着代码一级一级往里看，效率太低了。

我在代码里还会保留一个currentTokenStart指针，记录当前token从哪里开始。这样报错信息能带行号列号。很多同学忽略了这一点，后面语法分析实验需要定位错误位置时，只能回头补，很痛苦。

2.2 三个最容易写崩的边界：EOF、注释、转义

词法分析实验的测试点，几乎总是围绕边界条件做文章。我自己调试时吃过不少亏，这里列三个重点。

关于EOF，最常见的写法是while ((ch = getchar()) != EOF)，这种写法有个隐藏问题——当读到最后一个字符时，如果你不把当前已经累积的token发给输出，最后一个标识符就凭空消失了。正确做法是：循环结束后，检查状态机是否还停留在某个非初态，如果是，必须补发一次“token结束”事件。我当年就是因为没处理EOF，导致最后一个标识符总是缺失，WA了整整一个下午。

关于注释，如果语言支持//行注释和/* */块注释，状态机里要专门为注释开辟状态。这里注意一个细节：块注释可能跨行，所以进入注释状态后，遇到换行不能当作token分隔符，而是要继续留在注释状态里。还有，如果测试用例里有/* /* */这种嵌套注释，你要提前想好到底支持不支持，不支持的话就要把嵌套注释判定为错误输入，否则程序行为会不确定。

关于字符串转义，字符串常量里常出现\"、\\、\n这样的转义序列。如果你在循环里看到"就认为字符串结束，那printf("He said \"hi\"");这种合法代码会被你的词法分析器拦腰截断。正确的处理是：在字符串状态内部，遇到\时要跳过下一个字符，不管它是什么。

3. 语法分析：递归下降是课设实验最务实的一档

过了词法分析这一关，后面的语法分析实验往往是整个系列里最让人头秃的。因为理论课讲了LL(1)、LR(1)、算符优先、SLR一大堆方法，你反而不知道到底该用哪个上机。

3.1 为什么不用yacc/bison而是手写递归下降

我先给个简单的对比，大家感受一下。

我的理由很简单：OJ上你没法保证有flex、bison这些工具可用。就算本机装了，提交给OJ的是一个完整的源文件，你不可能把yacc生成的一大坨代码直接交上去。与其依赖自动生成，不如手写递归下降。

递归下降的核心思路是：每一个非终结符写一个解析函数，函数体里按照该非终结符的产生式，依次调用终结符匹配函数和其他非终结符的解析函数。这样做的好处是，代码结构跟文法是一一对应的，出错了你能直接定位到某个文法符号的处理逻辑。

3.2 消除左递归与FIRST/FOLLOW，这两步别偷懒

手写递归下降最大的敌人是左递归。比如经典的四则运算文法：

E -> E + T | T T -> T * F | F F -> ( E ) | id

直接照这个写法实现parseE()，调用自己会无限递归，栈直接爆掉。所以必须先把左递归消除掉，转换成右递归形式：

E -> T E' E' -> + T E' | ε T -> F T' T' -> * F T' | ε F -> ( E ) | id

消除之后，parseEprime()里就有个分支：如果当前token是+，就消费掉并继续解析T和E'；否则就直接返回，表示 ε 产生式。

FIRST集和FOLLOW集的计算别看它理论性强，实际写代码时非常有用。比如上面这个文法，E'的FIRST集就是{+, ε}，这直接告诉你parseEprime()里该什么时候走+分支。FOLLOW集决定了某个非终结符在什么情况下算“结束”。

我建议你在动手写代码前，先把每个非终结符的FIRST和FOLLOW集合用手算一遍，然后把结果作为注释写在对应函数上面。这样写代码不是拍脑袋，而是有依据的。很多同学跳过这步，结果就是函数里各种if条件凭感觉写，遇到边界输入就开始乱报错。

3.3 panic模式下怎么恢复错误

语法分析实验还有一个隐藏考点：遇到语法错误时，程序不能崩，而且要按照预期输出错误信息。这就涉及错误恢复策略。

最简单的、也最适合OJ的做法是panic模式。核心思想是：当解析函数发现当前token跟期望的不匹配时，不立刻终止整个程序，而是调用一个synchError()函数——跳过输入流里的一系列token，直到遇到某个“同步符号”为止。同步符号通常是分号、右括号这些标志着一个语句或一个子表达式结束的词法单元。

代码骨架大致是这样：

void match(int expected) { if (lookahead == expected) { lookahead = nextToken(); } else { errorReport("syntax error: expected " + tokenToString(expected)); synchronize(); // 跳过直到同步token } } void synchronize() { while (lookahead != SEMI && lookahead != RPAREN && lookahead != EOF) { lookahead = nextToken(); } }

这里有个关键点：synchronize()里跳过了错误输入，但你不能把同步符号也吞掉，否则后面的解析会乱套。通常的做法是停在这个符号上，让上层函数来决定是否消费它。这个细节我在第一次实现时吃了亏，总是跳过同步符号之后，分号就莫名其妙“消失”了，导致一直连环报错。

4. 中间代码生成：把“看懂语法”变成“算得出结果”

如果你所在的实验系列做到了中间代码生成这一步，恭喜，你已经扛过了最痛苦的部分。但是别高兴太早，中间代码生成是一门“看起来不难、做起来全是细节”的手艺。

4.1 符号表的结构设计

符号表是语义分析的核心数据结构。我见过的最常见的错误是：把所有变量都塞进一个全局哈希表里，不管作用域。这样写最直接的后果是，两个不同作用域里的同名变量会互相污染。

正确做法是作用域链式结构：每个作用域对应一个哈希表，所有作用域串成一个链表。查找变量时，从当前作用域开始，一层一层往上找。插入变量时，只插入当前作用域。退出一个作用域时，就把当前这一层哈希表整个丢弃。

struct SymbolTable { std::unordered_map<std::string, SymbolInfo> symbols; SymbolTable* parent; }; SymbolInfo* lookup(const std::string& name, SymbolTable* scope) { while (scope != nullptr) { auto it = scope->symbols.find(name); if (it != scope->symbols.end()) return &(it->second); scope = scope->parent; } return nullptr; }

看起来简单，但作用域的进入和退出点在哪里，很多人拿不准。我的经验是：每解析到一个{就新建一层作用域，每遇到对应的}就退出一层。这个时机处理好了，后面做变量重名检查、类型检查都会顺手很多。

4.2 四元式生成的临时变量管理

中间代码最常用的表达形式是四元式：(op, arg1, arg2, result)。比如表达式a = b + c * d，标准的三地址代码是这样：

t1 = c * d t2 = b + t1 a = t2

这里的关键问题是临时变量t1、t2怎么管理。我的习惯是弄一个全局计数器tempCount，每次需要新临时变量就++tempCount，拼接成t1、t2这样的名字。这个计数器在整个程序结束前不能重置。

还有一个容易搞错的是运算顺序。生成四元式时，必须保证先算的操作数先生成对应代码。拿b + c * d来说，如果语法分析树给出的结构是+(b, *(c, d))，你就应该递归地先生成c * d的四元式，把结果放到临时变量里，再生成b + 临时变量的四元式。如果你把顺序写反了，表达式结果可能碰巧对，但临时变量的使用顺序会跟标准答案不一样，OJ比对输出时照样判WA。

4.3 用“手工求值”验证中间代码

中间代码对不对，最笨也最有效的方法就是手工求值。你可以准备一个非常简单的例子，比如：

a = 2 + 3 * 4; b = a * 2;

然后自己按运算优先级在草稿纸上算一遍，得到期望的四元式序列，再去对比你程序输出的四元式序列。这个方法看起来原始，但真的能抓出很多隐蔽问题。

我还会把中间代码“当成指令来模拟执行”。说白了就是自己手动维护一个变量表，沿着四元式列表一行一行地“执行”，看最终变量的值跟原程序在语义上是否一致。如果中间代码每步都正确，通常你的程序最终结果就不会差。

5. 绕不开的OJ疑难杂症：RE、TLE、WA排查链路

即使你的逻辑完全正确，OJ依然可能给出让人崩溃的判定结果。这里把最常见的三类问题单独拎出来说，都是我自己和身边同学踩过的。

5.1 运行时错误（RE）的常规排查顺序

RE是编译原理实验里最让人抓狂的，因为你的程序本机几乎不可能复现。按这个顺序排查，大概率能定位：

首先查数组越界。词法分析里状态转移表是用数组实现的，如果输入字符的类别值超出了数组维度，或者token缓冲区满了但没有扩容，就会越界。排查方法是：把所有数组下标访问都过一遍，确认边界条件。尤其是状态转移表，charClass(ch)的返回值必须被你限制在一个安全范围内。

接着查空指针和非法内存访问。符号表查找函数找不到变量时返回nullptr，如果你没有处理就直接访问其成员，那就RE了。对策是：查找不到时，至少打印一条错误信息再终止，而不是傻愣愣地崩溃。

然后是递归爆栈。递归下降解析超长表达式时，递归深度可能非常大。有一种隐蔽的情况：某些OJ使用较小的栈限制，本机能跑的递归深度到了OJ上就爆。及时发现的办法是，在一段超深输入上本地测试，看是否Segmentation fault。

5.2 超时（TLE）的常见热点

编译原理实验按理说不会像算法题那样卡常数，但存在几类非常典型的低效写法。

第一类是过度使用字符串操作。比如在你的词法分析里，每读一个字符就string += ch，这没问题；但如果每读一个字符就生成一个子串去查保留字表，那就是灾难。解决方法是：只在token累积完成后，才对完整的字符串做哈希查找。

第二类是低效的查表结构。如果状态转移表用了map<pair<int,int>, int>或unordered_map而不是二维数组，每次字符转移都需要哈希计算，输入一长，TLE就出现了。改用二维数组之后，速度能提升一个数量级。

第三类是频繁刷新输出缓冲区。std::endl不仅换行，还强制刷新缓冲区。在循环里输出几千个token时，每次刷新都是性能杀手。改成\n，性能立刻改善。

5.3 答案错误（WA）的隐蔽陷阱

WA是最让人头疼的，因为程序没崩也没超时，就是输出不对。我总结了几类特别隐蔽的坑。

输出格式的“字符级”问题：多了一个空格、少了一个换行、大小写不一致，都会WA。有个土办法：把你程序的输出保存到文件，跟OJ给的样例输出文件做逐字节比对。用diff命令看差异，一眼就知道问题在哪。

保留字和标识符的处理顺序也会造成WA。如果你的词法分析器先把所有单词都识别成标识符，再查表判断是不是保留字，那么“if”、“else”这些关键字，必须在你查保留字表后、输出token类型时变成关键字类型，而不是标识符类型。这个顺序写反了，语法分析阶段会觉得整个程序全是语法错误。

还有四元式的临时变量名格式问题。标准答案用t1、t2，你用了tmp1、tmp2，功能正确但格式不匹配，OJ判WA。做实验之前一定先仔细读题目要求的输出格式，看清每个字段的精确写法。这是我见过的最冤的一种WA。

5.4 本地对拍与判题模拟

最后一个压箱底的技巧：自己给自己造一个“假OJ”。

写一个随机测试用例生成器，专门生成各种合法的、非法的程序片段，然后把你编译原理实验的程序跑上去，跟一个自己写的简易参考实现比输出。这个过程叫对拍。对拍脚本不用复杂，一个shell脚本就能胜任：

for i in $(seq 1 1000); do ./generator > input.txt ./my_compiler < input.txt > my_output.txt ./reference < input.txt > ref_output.txt if ! diff -q my_output.txt ref_output.txt > /dev/null; then echo "Case $i failed" break fi done

用这种方式，可以在提交OJ前就发现九成的问题。我当年做中间代码生成实验时，就是靠一个随机生成算术表达式的脚本，抓到了三个隐藏很深的错误。

另外一个好用的小技巧是，在本地模拟OJ的资源限制。Linux下可以用/usr/bin/time -v ./my_compiler < input.txt查看程序运行时间和最大内存占用。如果发现某个极限输入耗时不正常，不要慌，先用二分法定位是哪个模块耗时高，通常问题都出在字符串操作或循环结构上。

结语：几个过来人的锦囊

文章最后，分享几个我自己在实操中沉淀下来的小经验，希望能帮你少走一点弯路。

第一个是：每个实验结束后，把“能过OJ的那一版代码”单独归档。千万别在原有代码上直接开新功能。我做这批实验时，每个阶段都建了一个独立目录，F实验的代码完整保存，G实验开始时复制一份再去改。因为后面实验做挂了，你随时可以回到上一版验证是不是基础组件出了问题。

第二个是：写词法分析时，就顺手把行号、列号、token类型、token值这些信息完整保留。哪怕当前实验没要求输出，也一定要存着。后面的语法分析、语义分析、报错定位全都用得上，现在多写几行，后面能省一个晚上。

第三个是：不要一直停在“本地不报错”的舒适区。OJ对格式的敏感程度远超你想象，提交前务必用diff逐字节比对输出，尤其是那些看似无关紧要的空格和换行。你以为OJ会大方地忽略这些差异，实际上它严格得很。

这批F到M的实验熬过去以后，你会发现自己对编译器“从文本到可执行代码”这条流水线的理解，会达到一个前所未有的高度。代码写得怎么样、OJ成绩漂不漂亮是一回事，真正把词法、语法、语义、中间代码这几座大山翻过去之后，再回头读那些厚得像砖头的教材，你会觉得书里写的东西，终于都活起来了。