编译原理课后习题答案使用指南：从词法分析到Flex+Bison实践

简介：《编译原理及实践》是编译技术入门到进阶的常备教材，这份PDF是配套课后习题答案，适合计算机专业学生、考研复习者以及自学编译器原理的开发者。资源围绕词法分析、语法分析、语义分析、中间代码生成、代码优化、目标代码生成与错误处理等核心章节展开，按题给出解析与实现思路，能帮助读者对照教材巩固理论、理解编译器整体工作流程。包内为1个PDF文档，压缩包大小3.75MB，内容集中、便于按章节查阅。目前已有1545人学习下载。借助这份答案解析，读者可快速定位习题难点，学习ANTLR、Flex与Bison等工具在词法/语法分析中的典型应用，并参考三地址码生成、死代码删除、循环展开等优化策略，为课程设计、项目实战或后续深入研究打好基础。

1. 编译原理及实践课后习题答案PDF：它是“黑匣子”的拆解说明书

《编译原理及实践课后习题答案.pdf》这个名字在高校课程群里被传来传去，不是因为大家想偷懒，而是因为编译原理这门课的课后题实在特殊：别的科目答案对一下数字就完事，编译原理的答案却是一整张 LL(1) 分析表、一整棵语法树、一整台状态机。你对着教材做词法分析章节的习题，写出一个 NFA 再转 DFA，怎么知道等价的 DFA 到底该长什么样？答案 PDF 就是干这个用的——它把标准推导路径摆出来，让你能精确定位自己是在子集构造算法哪一步跑偏。适合正在修“编译原理”的学生，也适合准备复试或面试前突击词法、语法分析的工程师。但凡是只抄不验的，后面实验和面试都会还账。

2. 先拆题型再对照答案：课后习题的考法与答案PDF的正确打开方式

编译原理教材的课后题看起来千变万化，但落到考卷上就是几个固定题型。第一次翻开答案 PDF 之前，我建议你先拿一支笔把教材目录过一遍，标出哪些章节配了计算题、哪些配了构造题，再决定这份答案要重点翻哪几页。否则你会在找第二章答案时翻到一大堆正则表达式，自己却还在第一章纠结什么叫编译前端。

2.1 课后题的五大题型与对应考点

我按最常见的教材编排顺序，把“编译原理”课后题拆成五类：

这五类题的共同点是“标准答案很长、推导过程可追踪”。和数学题不一样，编译原理答案的每一步都来自某条明确规则：求 FIRST 集时先看产生式右部首符，若首符是非终结符则递归查它的 FIRST；若某一串全都能推出 ε，才把 ε 并入。这些规则一旦讲清楚，答案 PDF 就不再是“谜底”，而是可复现的推导日志。

词法分析题尤其看重“状态”这个概念。教材里的习题让你写一个识别某个正则语言的 DFA，答案一般会给出状态转换表，并标出哪些状态是接受态。你在对照时不要只看最终表，要看它有没有把死状态画出来——很多同学漏了死状态，导致 DFA 不完整。语法分析题则看重“集合计算”的次序，FIRST 集、FOLLOW 集、SELECT 集的构造顺序错一步，后面预测分析表全错，这块也最值得和答案仔细核对。

2.2 先做再对照：答案PDF的正确使用顺序

我一般不建议直接翻开答案做题，那会白白浪费这门课最重要的训练——手工模拟。更推荐下面这个顺序，对着一道大题做：

1. 自己不看书、不看答案，把推导和构造写完整。例如给文法 G[S]: S→aAB，A→Bb|ε，B→dB|ε，手算 FIRST(A)、FOLLOW(A)。
2. 书合上，用“规则自检”过一遍：检查有没有遗漏 ε 产生式；FOLLOW 计算时，是否把 A 后面紧跟的终结符和 B 的 FOLLOW 合并了。
3. 打开答案 PDF，只对照关键步骤：看它的 FIRST 集合里有没有 ε，看 FOLLOW[A] 是否包含了 $（输入结束符）。
4. 如果对不上，把答案和自己的推导逐行摆同一张纸上，从第一次出现分叉的地方往回找规则。

这样走完一遍，一道题顶你抄三道题：你不仅知道对的答案长什么样，还知道“错的那个答案是怎么推导出来的”。很多课后题答案会在题号后面标注教材版本或章号，比如“编译原理清华大学出版社第三版第二章答案”，你要做的不是记住这个编号，而是确认自己正在用的版本是不是同一年代。第二版与第三版在“语法制导翻译”和“中间代码”两章的习题顺序常有调整。

另外，答案 PDF 本身也是分章节的。有的文件把“词法分析”和“语法分析”揉在一起，按题号排，不按章排；有的则按章归档。拿到文件后第一件事，不是看第一章答案，而是先找题号索引或目录页，确认它覆盖了从“正则表达式”到“目标代码生成”的哪个范围。否则你会为了找一道 LR(1) 的题，把整个 PDF 从头翻到尾。

怎么判断一份答案值不值得信任？我只说一条：看它给不给中间过程。只给最终 FIRST 集、不给推导步骤的答案，对你没有任何学习价值；真正好的答案每个集合都标了“由产生式 3 + 产生式 5 求并得到”之类来源。如果手头这份只有结果，那就把它当作最终验收值，自己把过程补全后再比对。

2.3 版本差异有多坑：清华第三版、第二版与院校自编版

课后题答案最怕的不是题难，而是版本错位。同一个文法，清华第三版可能编号为习题 2.3，第二版里却是习题 2.6；更麻烦的是，有些院校用自编讲义，“山东科技大学编译原理”这类课程网站上的题目会把多个教材的习题混在一起。我处理过一份山科大同学发来的作业，它要求构造的文法在某一版答案 PDF 里根本找不到——不是因为题超纲，而是因为两本书在第二章收纳的词法分析题目先后顺序不同。

我的判断方法很简单：先翻答案 PDF 里第一道题对应的文法，再和自己教材上的原文对比。如果文法符号（比如 M→L.M|L 里的小数点）一致，大概率版本对口；如果连终结符的命名习惯都不同，那就别硬对答案了，你要找的是另一份“编译原理第三版答案”。这个版本核对步骤花不了两分钟，却能把后面十几个小时的返工全省下来。

在版本这件事上还有一条隐藏规则：教材改版时，语法分析章节往往只调题目顺序、不改文法本身；而语法制导翻译章节却经常改属性定义方式，比如把“继承属性”的写法从显式参数改成隐式上下文。所以如果你卡在中间代码那几章，版本不对就别勉强用旧答案，宁可找找课程组发的讲义。

3. 把课后题变成能跑的真代码：词法分析与语法分析习题的落地实现

课后题做到第六题，很多人会有个共同念头：这些东西能不能跑一下看看？“编译原理实验”课一般就是顺应这个念头设计的。与其在纸上画完 DFA 就丢，不如写一个几十行的词法分析器，把第二章节的自动机理论变成看得见的 token 流。下面两段代码我分别用 Python 和递归下降法实现，它们对应课后题里最常见的两类题：识别单词、解析表达式。

3.1 用Python实现一个最小词法分析器

先给代码，再讲为什么这么写。这段实现对应“识别 C 语言子集关键字、标识符和整数”的课后题：

import re # 关键字表：大小写敏感的保留字，可自行扩充 KEYWORDS = {"if", "else", "while", "return", "int", "void"} # 词法规则：顺序即优先级 TOKEN_SPEC = [ ("NUMBER", r"\d+"), # 整数常量 ("IDENT", r"[A-Za-z_]\w*"), # 标识符 ("ASSIGN", r"="), # 赋值号 ("OP", r"[+\-*/]"), # 四则运算符 ("LPAREN", r"\("), # 左括号 ("RPAREN", r"\)"), # 右括号 ("SKIP", r"\s+"), # 空白，直接丢弃 ] TOKEN_RE = re.compile( "|".join(f"(?P<{name}>{pattern})" for name, pattern in TOKEN_SPEC) ) def tokenize(code: str): tokens = [] for m in TOKEN_RE.finditer(code): kind = m.lastgroup value = m.group() if kind == "SKIP": continue if kind == "IDENT" and value in KEYWORDS: kind = "KEYWORD" tokens.append((kind, value)) return tokens # 测试：对应课后题“识别if/while/return等关键字” sample = "int a=10; while(a>0) { a=a-1; } " for tok in tokenize(sample): print(tok)

这里有几个关键点。命名分组(?P<name>pattern)让正则匹配后能通过m.lastgroup直接拿到 token 类型名，省去再写一次分支判断。规则顺序就是优先级：把 NUMBER 放在 IDENT 前面，是为了让10abc这种非法输入先吃出整段数字再报错；实际产品里这种写法不够健壮，但做课后题正好够用。IDENT命中后先查 KEYWORDS，把if、while从普通标识符里挑出来，这是每个词法分析器都要有的“关键字优先于标识符”处理。SKIP规则必须和普通符号规则放在同一个交替里，因为空白字符串如果单独在外面循环跳过，正则的finditer会把位置切错。

参数调整上，KEYWORDS 集合就是状态转换表里的“终结状态集合”。你要支持do、for，直接往集合里加；要支持浮点数，把 NUMBER 改成r"\d+(\.\d+)?"，但注意这时整数分支要排在浮点分支前，或者用负断言，否则1.2会被切成1和.2。我一般保留整数分支在前，让它作为第一现场，调试时也直观。

3.2 用递归下降法实现一个表达式解析器

词法分析通了之后，“语法分析”习题常拿表达式文法开刀。下面代码把文法 E→E+T|E-T|T、T→T*F|T/F|F、F→(E)|num 消掉左递归后，翻译成递归下降函数：

class Parser: def __init__(self, s: str): # 去掉空白后逐个字符扫描，i是当前读指针 self.s = s.replace(" ", "") self.i = 0 def peek(self): if self.i >= len(self.s): return None return self.s[self.i] def eat(self, ch): if self.peek() != ch: raise SyntaxError(f"pos {self.i}: expect '{ch}', got '{self.peek()}'") self.i += 1 def parse_expr(self): # expr -> term ((+|-) term)* val = self.parse_term() while self.peek() in ("+", "-"): op = self.peek() self.eat(op) right = self.parse_term() val = val + right if op == "+" else val - right return val def parse_term(self): # term -> factor ((*|/) factor)* val = self.parse_factor() while self.peek() in ("*", "/"): op = self.peek() self.eat(op) right = self.parse_factor() val = val * right if op == "*" else val // right return val def parse_factor(self): # factor -> num | '(' expr ')' if self.peek() == "(": self.eat("(") val = self.parse_expr() self.eat(")") return val val = 0 while self.peek() is not None and self.peek().isdigit(): val = val * 10 + int(self.peek()) self.eat(self.peek()) return val # 测试：2 + 3 * (4 - 1)，关键点是优先级与括号 p = Parser("2 + 3 * (4 - 1)") print(p.parse_expr()) # 应为 11

这段代码和课后题“画出递归下降子程序框图”几乎是逐行对应。parse_expr先调parse_term，把加减法的优先级压到乘除法之下；parse_factor遇到左括号就递归调用parse_expr，正好对应文法F→(E)。每个非终结符一个函数，函数之间互相调用，这和预测分析表驱动的方式不同，但对 LL(1) 文法是成立的。这里的//是整数除法，如果课后题要求实数运算，直接改成/。

参数说明：读指针self.i是这个解析器唯一的状态量。如果你想支持负数，需要在parse_factor里加一个单目减分支；如果你想支持变量名而不是纯数字，把parse_factor的数字循环换成一个查表取变量值。很多“编译原理实验”课的语法分析题要求的就是这个级别：能正确解析、能报错就行。报错时eat方法抛出的位置信息，就是课后题里“分析器遇到非法符号应该给出错误提示”的实现。

3.3 手写解析器和自动生成器怎么选

到这里你会发现，课后题里那种“手工构造预测分析表、手工模拟匹配过程”的训练和真实工具是两条路。做题时，一定要用手推表、手写递归的函数；落到课程实验或实际项目时，我更倾向于用效率更高的 Flex+Bison，或者直接用一棵手工维护的语法树结构。手写递归下降适合文法不大、想完全控制报错信息和恢复策略的场景；自动生成器适合文法有几十条产生式、需要 LR 全家桶的场合。两者并不冲突，先手写一遍，再用自动工具生成一遍，把两边输出互相对照，这就是答案 PDF 最好的使用方式——把标准答案当测试用例。

4. 从课后题到编译原理实验：Flex+Bison最小工程与常用命令

“编译原理实验”最常见的形态是：给你一个 C 语言的子集，让你用 Flex/Bison 写一个能识别语法并计算的小程序。它和课后题的差别在于，不再手推分析表，而是让工具自动构造 LALR(1) 分析器。很多第一次接触的人以为 Flex 和 Bison 很难，其实核心就是两个文件：一个.l写词法，一个.y写文法，然后用两条命令生成 C 代码，再一条命令编译运行。

4.1 安装与版本选型：三行命令

不同操作系统安装命令差别很大，先说结论：

安装后先验证版本：flex --version和bison --version。Bison 3.x 的语法和 2.x 不完全兼容，比如%define api.value.type这种写法只在 3.x 可用。如果你是照着旧教程抄的.y文件，报错很可能出在这，不要一上来就怪文法难。Windows 下踩过最多的坑是生成出来的 C 文件在 mingw 里编译报找不到unistd.h，后面第 5 章专门讲。

4.2 最小词法文件.l与语法文件.y的骨架

先建expr.l：

%{ #include <stdio.h> #include "expr.tab.h" /* 由 bison -d 生成，定义 NUMBER 等 token 宏 */ %} %% [0-9]+ { yylval = atoi(yytext); return NUMBER; } [ \t\n] ; /* 空白直接跳过 */ . { return yytext[0]; } /* 其他字符按原符号返回 */ %% int yywrap(void) { return 1; }

再建expr.y：

%{ #include <stdio.h> extern int yylex(void); void yyerror(const char *s) { fprintf(stderr, "err: %s\n", s); } %} %token NUMBER %left '+' '-' %left '*' '/' %% expr: expr '+' term { $$ = $1 + $3; } | expr '-' term { $$ = $1 - $3; } | term { $$ = $1; } ; term: term '*' NUMBER { $$ = $1 * $3; } | term '/' NUMBER { $$ = $1 / $3; } | NUMBER { $$ = $1; } ; %% int main(void) { return yyparse(); }

编译命令：

bison -d expr.y # 生成 expr.tab.c 和 expr.tab.h flex expr.l # 生成 lex.yy.c gcc expr.tab.c lex.yy.c -o expr echo "3+4*5" | ./expr

逻辑说明：bison -d必须第一个跑，因为它生成的expr.tab.h里定义了NUMBER等 token 的宏编号，expr.l里#include "expr.tab.h"才能对上号。%left告诉 bison 加减法和乘除法分别是左结合，并且下面的行优先级更高，这样3+4*5会先算4*5。动作里的$$ = $1 + $3是语法制导翻译的最直接体现：归约expr '+' term时，把第 1 个和第 3 个符号的属性值加起来存到左部非终结符上。

参数说明：如果你想支持用-做负号而不是减号，需要在%token里单独声明一个NEG，文法里写成term: '-' term { $$ = -$2; }，并把%left NEG放在乘除法之上（越靠后优先级越高）。这是课后题里“处理二义性文法”的经典考点。另外，.l文件里[ \t\n] ;必须写分号表示空动作；漏了分号 flex 会直接报错，我第一次写就吃过这个亏。

4.3 用实验数据反向验证答案里的FIRST/FOLLOW集

Flex+Bison 本身不直接输出 FIRST/FOLLOW 集，但你可以写一个十几行的小脚本，用它生成集合再和答案 PDF 对照。下面这个 Python 函数用递归求一个非终结符的 FIRST 集：

def first(grammar, symbol, seen=None): # grammar: {'S': [['a', 'B'], ['ε']], ...} if seen is None: seen = set() if symbol not in grammar: return {symbol} # 终结符的FIRST就是它自己 if symbol in seen: return set() # 左递归保护，真正的文法里会先消左递归 seen.add(symbol) result = set() for prod in grammar[symbol]: if prod == ["ε"]: result.add("ε") continue for sym in prod: f = first(grammar, sym, seen) result |= (f - {"ε"}) if "ε" not in f: break else: # 产生式右部全可空，才有ε result.add("ε") seen.remove(symbol) return result g = { "E": [["T", "E_prime"]], "E_prime": [["+", "T", "E_prime"], ["ε"]], "T": [["F", "T_prime"]], "T_prime": [["*", "F", "T_prime"], ["ε"]], "F": [["(", "E", ")"], ["num"]] } for nt in g: print(nt, sorted(first(g, nt)))

这个脚本的核心逻辑是：递归向左移动时，每遇到一个右部符号就取它的 FIRST，去掉 ε 后并入结果；若某个符号不能推出 ε，就 break；若整条产生式右部都能为空，才往结果里加 ε。seen集合防止 E→T、T→F、F→(E) 这种互相引用导致无限递归。参数说明：把g换成你手头答案 PDF 里那道题的文法，输出的 FIRST 集直接和答案核对；对不上，优先检查是不是产生式抄错，再看是不是漏了“可空非终结符”。

5. 常见问题排查：课后题与实验中的五个典型翻车点

做编译原理题和实验，十次里有八次不是倒在原理上，而是倒在版本、环境和“没文化”上。下面五条是我见过也踩过的坑，按现象、原因、解决的顺序写，方便你直接对号入座。

5.1 答案PDF里的文法和教材对不上

现象：按教材的习题编号找答案，发现 PDF 里那道题的文法长得很像但有几处不同，导致 FIRST 集、分析表整个错位。原因：答案 PDF 是按某一版教材的习题顺序整理的，可能是第二版也可能是第三版，而你用的是另一版或院校自编讲义。解决：先对照题目里的文法符号而不是题号。如果 PDF 里的终结符命名、产生式顺序和教材一致，再继续算；不一致就换一份“编译原理第三版答案”，或按题目原文重新推导。这个核对动作我每次都做，尤其是在用“山东科技大学编译原理”这类课程资料时，讲义常把多个教材的题拼在一起。

5.2 FIRST集少算ε，FOLLOW集连环错

现象：求 FIRST(E) 时没有把 ε 放进去，结果 FOLLOW 集少了一个关键的 $，后面 LR 分析表整行规约冲突，怎么看都解释不通。原因：很多同学看到E→T E′就默认 E 不可空，忘了 E′ 可能推出 ε；当 E′ 可空时，FOLLOW(E′) 要把 FOLLOW(E) 并进去，这是嵌套推导里最容易被漏的一步。解决：单独列出所有“可空非终结符表”，逐条产生式更新，直到表不再变化为止。这是一张不动点迭代表，不是看一遍就能算完的。把自己算的 FIRST 集与答案 PDF 核对，ε 出现的位置只要对不上，后面全白做。

5.3 LL(1)分析表冲突时直接抄答案，左递归消除等于没学

现象：构造预测分析表时，某一格的入口出现了两个产生式，答案 PDF 却直接给出了最终表，于是你照着抄了个正确表格，但下次换个文法的题还是不会。原因：冲突的本质是文法不是 LL(1) 的，通常因为左递归没消干净或没有提取左公因子。抄答案绕过了“为什么冲突”，也就避开了这门课的核心。解决：回到原文法，先把直接左递归A→Aα|β改写成A→βA′、A′→αA′|ε，再算 FIRST 和 FOLLOW；仍然冲突时，检查是不是 SELECT(A→α) 和 SELECT(A→β) 交集非空。答案 PDF 应该只用来验证最终表，冲突的消解过程必须自己亲手做一遍。

5.4 Windows下Flex/Bison环境安装报错

现象：装好了 Flex，运行flex expr.l生成 C 文件，gcc 编译时报找不到unistd.h；或者 bison 版本太老，%define语法直接报 syntax error。原因：Windows 的 C 运行库和 POSIX 环境有差异，flex 生成的扫描器在非 MSYS 环境下需要额外兼容补丁；bison 2.x 和 3.x 语法差异大，教程混着看就翻车。解决：统一用 MSYS2 的 pacman 安装 flex 和 bison，并在 MSYS2 的 shell 里完成生成与编译，不要依赖 cmd；或者直接换 WSL，在 Ubuntu 里apt install flex bison。我一般优先 WSL，因为教材和课程实验基本都以 Linux 为默认环境，少踩很多玄学问题。

5.5 Java实验里字符流字节流混用，中文注释乱码

现象：用“java+编译原理”写词法分析器，读取源码文件时中文注释变成乱码，还连累后面的字符串匹配。原因：用FileInputStream读文件再传到String构造器，没有指定字符集；Windows 默认可能是 GBK，文件实际是 UTF-8，字节和字符错位。解决：读文件统一用Files.newBufferedReader(path, StandardCharsets.UTF_8)或new InputStreamReader(new FileInputStream(f), StandardCharsets.UTF_8)，全链路固定 UTF-8。这个坑在课程实验报告里写清楚，本身就是个不错的加分点：它说明你理解了“编译前端处理字节流与字符流的边界”。

6. 进阶验证：双实现互测，把答案PDF变成回归测试集

到这里，你已经能写词法分析器、跑 Flex+Bison、验证 FIRST/FOLLOW 了。最后一个技巧是把整份答案 PDF 当回归测试集用：用两套独立实现跑同一组题目里的输入，把两边输出的 token 流、语法树或计算结果互相对比。两边一致不代表绝对正确，但两边不一致一定有一处翻车，这时候答案 PDF 就变成了你的调试参照。

6.1 具体动作与我的收尾习惯

先挑课后题里的典型输入，比如3+4*5和(3+4)*5，先手写实现算一遍，再让 Bison 版算一遍，第三份结果与答案 PDF 的中间过程比对。三份一致，这道题才算真正吃透。我习惯在实验里再加一个--print-tokens参数，把.l文件里每个 token 依次打印出来，然后和答案 PDF 的词法状态转换表逐行核对。这个习惯帮我抓过不少把while当成普通标识符的错，也帮我确认过“哪一版答案把运算符优先级写错了”。其实 PDF 答案也有错，别迷信，一定要带着验证的心态去用。

我当年最快抄完一本题，后面面试被问“LR(0) 什么时候需要规约”直接卡壳，花了两星期才把这课真正补上。答案 PDF 的价值上限，取决于你自己动手下限；用对照实验的方式去用它，比抄十遍都管用。希望帮到你。

本文还有配套的精品资源，点击获取