简介：面向编译原理课程设计的高校学生，这份资源整合了完整的实验代码与报告，覆盖词法分析、LL(1)语法分析、LR(0)/SLR(1)语法分析、四元式生成及汇编代码生成等核心环节，适合作为课程设计或期末项目的参考蓝本。资源包共14个文件，以C/C++源文件（.cpp/.c/.h）为主，辅以3个文法说明文本和1份Word版实验报告，总体积557KB，方便直接阅读与编译调试。包内包含可运行的词法分析器、小型编译器，以及部分LL(1)文法和SLR(1)文法定义，并提供了简单语句（如i+i*i）的分析示例，便于对照理论理解语法分析流程。目前已有2342人学习下载，说明被较多学习者验证参考。借助这份资料，读者可以快速掌握从词法识别到中间代码生成、汇编输出的整体编译链路，同时结合报告梳理实验设计思路，节省自行搭建框架的时间。 开学第三周，实验室的走廊里又开始弥漫着编译原理课设独有的焦虑气息。你打开题目列表，翻到“词法分析+语法分析+小型编译器”这一项，想着无非就是写个脚本识别几个单词，结果GitHub上逛了一圈，发现别人动辄上千行代码，还有配套的图形界面和中间代码优化，心里瞬间没底了。
这个课设到底做到什么程度算完？老师说的“小型编译器”究竟要编译什么语言？实验报告怎么排版才能不让答辩现场变成大型社死现场？
我前前后后带过几届学弟学妹做这套题目，自己也拆过不下二十份优秀作业和踩坑案例，可以负责任地告诉你：这门课设的难点从来不是“写代码”，而是“设计边界”——你打算支持多少语法？错误处理做到什么粒度？AST要不要建？最终是生成汇编还是直接解释执行？
这篇我把自己做课设时的完整思路、代码骨架、测试方案和报告写法全部摊开讲。你不需要照抄我的实现，但要明白每一步决策背后的理由，遇到答辩追问时才能接得住。
1. 从需求出发：先定义“Mini语言”，再谈编译器
1.1 语言规范：不定义清楚，后面全是坑
很多同学一上来就写词法分析器，结果写了一半发现“else if”怎么处理、负数怎么解析、字符串转义要不要做，边写边改，最后代码里全是补丁。
我建议你先花半天时间，用一段话把你的目标语言定义清楚。我当时的定义是这样的：
- 支持整数、实数和布尔值三种基本类型
- 支持变量声明与赋值，变量必须先声明后使用
- 支持
+ - * /四则运算和%取模，优先级按数学惯例 - 支持关系运算
> < >= <= == !=，结果为布尔值 - 支持
if / else条件分支和while循环 - 支持
print内建函数输出 - 不支持数组、指针、函数定义（想加函数可以放拓展部分）
这个范围看起来不大，但它覆盖了词法分析、语法分析、语义检查的主要知识点，工作量又控制在两周以内能干完的水平。
更关键的是，把范围写清楚之后，你写代码的过程会变成“翻译规范”，而不是“试探边界”。每一次遇到含糊的地方，回到这条规范里去查，不该支持的语法直接报错，不需要犹豫。
1.2 架构选型：单文件跑通还是经典三段式
编译器经典架构分前端、中端、后端。课设阶段你不可能做完整的优化流水线，但至少要在代码结构上体现“分层”意识，因为实验报告里要画这个框图。
我的做法是分三个模块，放在同一工程下：
- 词法分析器（Lexer）：负责把源代码字符串拆成 Token 流
- 语法分析器（Parser）：负责拿 Token 流生成抽象语法树（AST），同时做语法错误检查
- 解释器（Interpreter）：负责遍历 AST，执行语句、计算表达式
这里要说明一下：我没有选择生成目标代码（汇编或字节码），而是直接解释执行 AST。原因很简单，课设要考察的是你对“词法-语法-语义”这条主链路的理解，解释器比生成汇编更容易写对，也更容易演示——你敲几行代码，它立刻输出结果，答辩效果远比跑一个.s汇编文件然后看寄存器强。
理论解释一下：词法分析做的是“字符流→单词流”的映射，语法分析做的是“单词流→语法树”的映射，而解释执行是“语法树→行为”。整条链路清晰对应编译原理课程里的各章标题，也是实验报告最好的目录。
2. 手写词法分析器：有限自动机没有你想的那么难
2.1 从字符流到Token流：状态机的工程实现
词法分析的核心是一个有限状态自动机（FEA）。理论上你可以在纸上画出状态转移图，然后照着写switch或者if，但实际工程里更常见的做法是“按类型逐个识别”。
先定义 Token 的数据结构：
class Token: def __init__(self, type, value, line, column): self.type = type # 标识符/关键字/数字/运算符/分隔符/结束符 self.value = value # 该 Token 对应的字符串或字面量 self.line = line # 行号，报错用 self.column = column # 列号，报错用type用一个枚举或字符串常量集合，至少要有这几个大类：ID（标识符）、KEYWORD（关键字）、INT（整数）、REAL（实数）、STRING（字符串）、OP（运算符）、DELIM（分隔符）、EOF（文件结束）。
接下来核心逻辑就三件事：
- 跳过空白和注释
- 根据当前字符的第一个字符决定进入哪个识别分支
- 识别出一个完整单词后停下来，查关键字表，区分“保留字”和“普通标识符”
这里要特别提醒一个坑：注释识别。很多人写完了//注释才想起来 C 语言风格/* */多行注释，然后狂改代码。我建议一开始就把两种注释都支持，逻辑不复杂：
def skip_whitespace_and_comments(): while current_char.isspace(): advance() if current_char == '/': peek = next_char() if peek == '/': # 单行注释，跳到行尾 while current_char not in ('\n', None): advance() elif peek == '*': # 块注释，找到匹配的 */ advance(); advance() while not (current_char == '*' and next_char() == '/'): advance() advance(); advance()2.2 标识符与关键字：先识别再查表，还是先查表再识别
这是每次答辩必问的问题：你如何保证if是关键字，而iffy是标识符？
标准做法是“按最大匹配识别出整个单词，然后去查关键字表”。也就是说，词法分析器并不知道if是不是关键字，它只是按 “字母开头，后面跟着字母/数字/下划线” 的规则把单词完整切出来，然后去一个预置的关键字字典里查一下。
keywords = {"if", "else", "while", "print", "int", "real", "bool"} def read_identifier(): result = "" while current_char.isalnum() or current_char == '_': result += current_char advance() if result in keywords: return Token("KEYWORD", result, line, col) return Token("ID", result, line, col)为什么不能“见if就停”？因为如果用户写的是ifx = 3，你看到i和f就停了，后面的x会解析成新的 Token，整个程序的语法就乱了。最大匹配原则是词法分析里最基础也最重要的规则，所有做过课设的人都应该能把它讲清楚。
2.3 数字识别：整数、实数、科学计数法
数字识别的状态图比标识符稍微复杂一点。最简单的情况是纯整数：一位到多位十进制数字。稍微进阶一点要支持实数：数字后紧跟小数点，小数点后至少一位数字。再进阶一点是科学计数法：1.2e-5。
这里有个细节容易被忽略：词法错误和语法错误的分界。比如输入123abc，到底该报什么错？我的做法是词法分析器识别出一个数字后，如果紧跟在后面的是字母，就抛出一个“无效字符序列”的词法错误。因为123abc在大多数语言里既不是合法的数字字面量，也不是合法的标识符，属于词法层面就该拦下来的东西。
2.4 运算符的坑：为什么不直接按字符读
运算符处理中最容易出问题的就是多字符运算符，比如==、>=、!=。你读到一个=时，必须“偷看”下一个字符：如果下一个是=，那这是一个“等于”运算符；否则这只是赋值号。
这种“向前看一个字符”的操作有一个形象的叫法：预读（lookahead）。整个词法分析器里需要预读的地方其实很多（比如注释识别也要预读），处理方式要统一。
我用 Python 实现时，把整个源码字符串作为列表存起来，维护一个pos指针，peek()函数只取值不移动指针：
def peek(self, offset=0): if self.pos + offset < len(self.text): return self.text[self.pos + offset] return None遇到=的时候这样处理：
if ch == '=': nxt = peek(1) if nxt == '=': advance(); advance() return Token("OP", "==", line, col) advance() return Token("OP", "=", line, col)3. 递归下降语法分析：不要背文法，要背“代码对应的树”
3.1 文法定义与消左递归：以表达式为例
语法分析我用的是手写递归下降，没用 Yacc/Bison 这类生成器。原因有三个：
- 递归下降的逻辑和你写的文法一一对应，代码读起来像读语法定义，调试直观
- 考试和答辩都默认你会手写分析器，这是硬技能
- 不需要额外的生成步骤和依赖库环境
先定义文法。以表达式为例，传统写法是：
E -> E + T | E - T | T T -> T * F | T / F | F F -> ( E ) | num这种文法左递归，递归下降没法直接写（函数会无限递归调用自己）。需要改写为右递归：
E -> T E' E' -> + T E' | - T E' | ε T -> F T' T' -> * F T' | / F T' | ε F -> ( E ) | num理论上你做到这一步就够了，但工程上还有更优雅的处理方式：用循环处理左结合。因为a - b - c在数学上是(a - b) - c，如果直接用右递归文法和尾递归函数实现，解析出来的树会变成a - (b - c)，计算结果是错的。虽然可以通过后续的树重写修正，但何必绕远路呢？
所以我的实现里，表达式解析采用“层次分解+循环”的方式，每一层函数返回一个“左值”，然后不断读取运算符和右边的操作数做左结合运算：
def parse_expr(self): # 处理加法级别：+ 和 - node = self.parse_term() while self.current_token.value in ('+', '-'): op = self.current_token.value self.advance() right = self.parse_term() node = BinaryOp(op, node, right) return node要跟答辩老师解释清楚：为什么循环能保证左结合？因为在每一次循环里，node都是“已经解析完的左边部分”，新的操作数只能成为右孩子，所以整棵树的根节点永远是最后处理的那个运算符，求值时也就自然满足从左到右的结合顺序。
3.2 每个语法成分对应一个函数：AST是怎么长出来的
递归下降的特色是“一函数一非终结符”。我程序里对应的函数：
parse_program()：解析整个程序，循环读取声明和语句parse_statement()：解析单条语句，按当前 Token 分发到分支parse_assignment()或parse_if()等parse_expr()：表达式parse_term()：乘除模parse_factor()：因子，包括数字、括号表达式、一元正负号
每个函数返回值是一棵子树的根节点。节点类型我一开始用 Python 的元组表示，后来发现可读性太差，改成了轻量级类：
class BinaryOp: def __init__(self, op, left, right): self.op = op self.left = left self.right = right class Const: def __init__(self, value): self.value = value这里有一个课设独有的大坑，十个人有九个会踩：一元负号到底归谁管。比如-3 + 5，词法分析器输出的是一个减号-和数字3；但语法分析走到parse_factor()时看到减号，是要解析成“一元负号”而不是“减法”。处理方法是在parse_factor()里加一个分支：
def parse_factor(self): token = self.current_token if token.type == 'OP' and token.value in ('-', '+'): self.advance() operand = self.parse_factor() return UnaryOp(token.value, operand) if token.type == 'INT': self.advance() return Const(int(token.value)) if token.type == 'OP' and token.value == '(': self.advance() expr = self.parse_expr() self.expect(')') return expr ...如果不处理这一层，-3 + 5就会被解析成“用 3 去减 5”，结果变成 -2，但你明明想表达的是 2。
3.3 错误处理：报错信息别只甩一个“Syntax Error”
我见过不少同学的程序，语法错误就打印一句 “Syntax Error”，然后退出。这种处理有两个问题：一是你自己调试时看不出错在哪一行；二是答辩时老师随便输一个错误程序，你连个像样的提示都没有，非常减分。
我用的策略是“Panic Mode”——遇到错误后记录错误信息，然后跳到下一行边界或同步符号继续解析。目标不是恢复出正确 AST，而是尽量多报告几个独立的错误，而不是卡死在第一个错误上。
具体实现方式很简单：写一个synchronize()方法，不断跳过 Token 直到遇到分号、右大括号或某个语句的开头关键字（比如if、while、print）：
def synchronize(self): while self.current_token.type != 'EOF': if self.current_token.value == ';': self.advance() return if self.current_token.value in ('if', 'while', 'print', '}'): return self.advance()同时，所有expect方法都会带上“期望值”和“实际值”以及行列号，方便用户定位。好的报错体验是实验报告里的加分项，我会在后文专门讲。
4. 语义分析与AST求值：符号表就是你的变量仓库
4.1 符号表设计：全局作用域就够了，但你要能回答“为什么不够”
严格的编译器需要维护多层作用域符号表，因为不同作用域允许同名变量，内层变量会遮蔽外层变量。
课设里如果你的 Mini 语言不支持函数，只支持全局作用域，那用一张哈希表就足够了。但别急着写dict，先把设计讲清楚：符号表只管“名字→属性”的映射，属性包括类型、存储位置（偏移量）、是否有初值等。
我当时的实现：
class SymbolTable: def __init__(self): self.variables = {} # name -> {"type": "int", "initialized": False} self.constants = {} # 也可以用同一个表 def declare(self, name, var_type): if name in self.variables: raise SemanticError(f"变量 {name} 重复声明") self.variables[name] = {"type": var_type, "initialized": False} def lookup(self, name): if name not in self.variables: raise SemanticError(f"变量 {name} 未声明") return self.variables[name]答辩时老师很可能会追问：“如果你加一个函数定义功能，符号表要怎么改？”你要能答出来：增加一张“函数表”，函数名映射到它的参数列表、返回类型和局部符号表；进入函数时压栈一个新的作用域表，退出时弹栈。虽然代码没写这些，但思路要储备好。
4.2 类型检查与求值：解释器怎么处理“先用后声明”
解释执行 AST 的过程，本质上是一个深度优先遍历。我写的Interpreter类里，核心方法就两个：visit(node)和evaluate(node)。
visit处理语句，负责流程控制（顺序、分支、循环）。evaluate处理表达式，返回计算结果。两者都维护一个env参数，也就是当前符号表。
这里有一个必须处理的语义错误：变量未声明就使用。比如：
x = 3; print y;词法分析没问题，语法分析也没问题（语句结构是规范的），但它违反了语言的语义约束。所以解释器每见到一个标识符引用，都要去符号表查一下，查不到就抛语义错误。
另一个常见语义约束是类型匹配。如果语言支持整数和实数，那么int x = 1.5应该抛出类型错误，或者做隐式类型转换。课设阶段我选择强制类型一致，更简单也更严格。
有个有意思的细节：条件表达式的位置。比如：
int x = 0; while (x) { ... } // x 是整数，当作布尔用，允许还是拒绝？严格类型检查应该拒绝，但很多语言（比如 C）允许隐式转换。我在课设里做了折中：定义bool的“真值规则”——整数 0 为假、非 0 为真，允许在if/while条件中隐式转换。这个决策要在实验报告的“设计要点”里写清楚，它是你做完语义分析的证据。
4.3 为什么不直接生成汇编：解释器给课设省下的三天
理论上“小型编译器”可以编译到 x86 汇编，然后再调用gcc把汇编变成可执行文件。但这条路对课设来说性价比太低——你至少要多写一整套寄存器分配、栈帧管理、调用约定的代码，Debug 难度指数级上升。
我选择解释执行属于“偷懒但符合题目要求”的做法。如果你想让项目看起来更“编译器”一些，可以做中间码：把 AST 转成三地址码（Three Address Code, TAC），然后用一个简单的虚拟机执行。比如：
t1 = 1 + 2 t2 = t1 * 3 x = t2三地址码的好处是：它非常接近汇编，又比汇编容易生成；可以顺便做简单的常量折叠优化（1 + 2直接算成3），在报告里能写一小节“基于三地址码的窥孔优化尝试”。
我当时为了让实验报告有亮点，加了一个很简单的“常量折叠”：解释器在evaluate二元运算前，如果左右两边都是常量，就直接计算结果，不再生成立即数的中间表示。代码量七八行，但能说明你理解了“优化”的动机。
5. 测试策略和踩坑实录：让程序自己证明“我写对了”
5.1 测试用例分层：从Hello World到递归调用
课设代码写完之后，最忌讳的就是只拿“输入加输出”两个用例就去答辩。合理的测试分层至少要有四层：
第一层：合法程序测试
int a; a = 10; print a; // 期望输出 10第二层：语法错误测试
int a; a = ; // 期望报错：表达式缺失第三层：语义错误测试
print unknown; // 期望报错：变量未声明第四层：边界测试
int a = 2147483647; print a + 1; // 整型溢出怎么处理这四层用例要单独建文件，每跑一个都记录输出和期望结果是否一致。我用了一个简单的 Shell 脚本批量跑，失败就标红，截图到实验报告里。
5.2 我掉过的坑：注释里的字符、负数、还有那个“中文分号”
这里说三个真实踩过的坑。
第一个是注释块没有处理“文件结束”。如果用户写了一个/*但没有闭合，词法分析器的while循环直接越界崩溃。修复方法是加文件末尾判断，然后报“未终止的块注释”。
第二个是负数赋值与运算符混淆。int x = -3;在语法上怎么处理？ 我一开始把一元负号放到parse_term里处理，结果a - -b这样的双负号永远解析不对。正确位置就是在parse_factor，而且递归调用自己，因为一元运算是最高优先级，再往下直接是原子成分。
第三个最有意思——中文字符悄然混入源码。我的一个测试用例文件被编辑器顺手存成了带 BOM 的 UTF-8 格式，词法分析器读到的第一个字符不是i而是\xef\xbb\xbf，直接报“无效字符”。后来我在词法分析器开头加了一行跳过 BOM 的逻辑，终于消停了。这个小处理可以在答辩的时候提一下，算深入工程细节的证明。
5.3 断言式自检：让“解释器不可能错”成为可验证的结论
除了人工准备用例，我建议代码里内置一层“内部断言”。
比如算术运算解释结果的计算过程，可以用 Python 的assert做一致性校验。举个例子，常量折叠后结果要和直接计算一致：
def eval_binary(op, left, right): folded = None if isinstance(left, Const) and isinstance(right, Const): folded = compute_now(op, left.value, right.value) assert folded == compute_slow(op, left.value, right.value) # 一致性检查 ...这一招不是必须的，但它能让你的同学和老师感受到“这个人真的在写工程，而不是交作业”。
6. 实验报告写法：把“我认为”升级为“我验证过”
6.1 报告的骨架：按编译流程组织，而不是按时间流水账
实验报告最容易写得像“开发日志”：“第一天写了词法分析，第二天写了语法分析……”这是大忌。老师要看的是你“如何做设计决策”，不是看你“花了几天”。
我的报告目录是：
- 需求分析：语言规格定义、支持的语法成分、错误处理策略
- 总体设计：模块划分、数据流图（字符流→Token流→AST→执行结果）、各模块接口定义
- 详细设计：词法分析的状态机描述（表格形式）、文法产生式、递归下降函数逻辑、符号表设计、解释执行流程
- 测试与分析：四层测试用例、每个用例的截图和输出说明、发现的 Bug 与修复过程
- 总结与心得：关键技术难点、个人收获、可拓展方向
注意“测试与分析”是最大得分区，这里一定要有“发现问题→定位→修复”的记录。比如：
测试用例
print 5 % 2;时发现取模运算符不被词法分析器识别。定位后发现运算符表中遗漏了%，导致语法分析时直接进入错误恢复。修复后补充了对应测试，验证通过。
这种记录比任何漂亮的架构图都有说服力。
6.2 绘图与表格：实验报告里哪些图值得画
实验报告里通常要求画图。我建议画三张就够：
第一张是词法分析器状态转移图：这幅图要精确到能看出状态机的边界条件，比如“数字后面紧跟字母→报错”的转移。
第二张是模块结构图：展示词法、语法、解释器三个模块的依赖关系，以及各自输出的数据结构。
第三张是关键流程代码逻辑图：我画的是表达式解析的调用关系，展示parse_expr如何调用parse_term，parse_term如何调用parse_factor，体现递归下降的关系。
表格则重点做两张：Token 类型划分表和运算符优先级表。前者把每种 Token 类型和对应模式列清楚，后者把优先级写明白。这两张表直接说明你的词法、语法设计是有规划、成体系的。
6.3 答辩自检清单：这些问题最好提前想好答案
最后送你一份我总结的答辩高频问题，建议在提交前对着自测一遍：
- 你的词法分析器如何区分关键字和标识符？
- 为什么表达式的解析要用“左结合”而不是“右结合”？
- 你的编译器报错时，是怎么定位错误的？
- 变量声明和赋值之间的语义约束在哪里检查？
- 如果让你加函数支持，语法层和语义层分别要改什么？
- 你做的这个“编译器”和真实编译器（如 GCC）的主要差异是什么？
最后一个问题尤其容易卡壳。比较稳妥的答法：真实编译器在前端之后还会做中间表示生成、多趟优化、寄存器分配、目标指令选择，最终生成汇编/机器码；我的课设止步于语法树解释执行，没有生成目标代码。这不叫“缩水”，而是明确地做了范围取舍，把重点放在词法与语法分析的完整性上。
根据我个人带课设的经验，能在报告里坦诚写出“哪些没做、为什么不做”的人，往往比堆了一堆跑不通的代码的人拿分更高。老师不指望你一个课设写出 GCC，他指望你证明自己懂了编译原理的主干脉络。
最后再分享一个小技巧：整个项目做完了之后，把第一周写的需求文档和最终代码里实现的功能做一次比对，把所有偏差列一遍，改到实验报告里，这段内容能让你在“总结与心得”部分写得异常真实。我当年的报告里写道：“原计划支持字符串变量，但考虑到转义字符与内存管理复杂度，最终仅支持字符串输出，不纳入变量体系。”老师看完之后，直接点头说这个取舍合理。
本文还有配套的精品资源，点击获取
