简介面向北京邮电大学编译原理课程实验学习者这份词法分析器实验包围绕编译器前端的关键环节展开帮助理解从字符流到词素序列的识别过程并可作为课程实验实现与复盘参考。压缩包共4个文件约10KB以2个txt说明与测试数据、1个h头文件和1个cpp实现为主分别承担实验说明、样例输入、符号/记号定义及扫描器核心逻辑结构精简便于快速定位词法规则定义、输入处理、分词与错误处理等模块。已有1000余人学习适合需要对照课程要求梳理词法分析流程的读者。通过阅读与调试其中的源码可观察正则式或词法规则如何映射为标识符、关键字、常量与运算符等词素并理解符号栈管理与异常情况下的恢复思路为后续语法分析实验打基础。1. 词法分析器编译器前端里最容易被低估的一环编译原理课程实验里词法分析器通常是第一个要交的东西很多人觉得它没什么技术含量——不就是把字符流切成一个个单词吗反直觉的地方在于错误提示的质量、语法分析器的状态数、甚至整个前端跑多快在词法分析这一层就已经基本定型了。一个把切成和的扫描器会让语法分析器凭空多出一堆冲突一个不记录行号列号的扫描器后面所有报错都只能给你一句「语法错误」形同黑匣子。词法分析器是整个编译前端里最小、最完整、能一晚上跑通的真实自动机搞懂它等于拿到了理解后续所有环节的第一把钥匙。2. 从字符流到 Token 流最长匹配和回溯是怎么省掉的词法分析器的输入是一串字符输出是一串 Token中间这段路看起来平淡但几乎所有实现层面的分歧都集中在两个问题上指针怎么推进以及「多看一个字符」这件事怎么表达。这一章先把扫描循环的最小骨架搭出来再解释最长匹配规则为什么会让「偷看」变成必需品。2.1 两个指针和一个哨兵扫描循环的最小骨架不管后面用 DFA 还是手写 switch扫描器内部基本都靠两个下标来支撑一个指向当前单词的起点一个指向「还没确定归属」的下一个字符。学院派教材里把它们叫lexemeBegin和forward实际代码里怎么命名无所谓关键是两者的语义必须清晰——forward之前的字符已经确定属于当前 Tokenforward之后的字符一概没看过。/* 扫描器的最小骨架lexeme_begin 是当前单词起点forward_idx 是下一个待读位置 */ static int forward_idx; /* 指向尚未消费的字符 */ static int lexeme_begin; /* 指向当前正在识别的单词的起始位置 */ /* 统一的字符读取入口所有推进都必须走这里 */ int next_char(Scanner *s) { int c s-input[forward_idx]; if (c \0) { return EOF_CHAR; /* 用 \0 当哨兵省掉每次读字符时的越界判断 */ } forward_idx; return c; } /* 只回退一个字符调用方负责保证不会退过头 */ void step_back(Scanner *s) { if (forward_idx lexeme_begin) { forward_idx--; } } /* 偷看不消费只返回下一个字符 */ int peek_char(Scanner *s) { int c s-input[forward_idx]; return (c \0) ? EOF_CHAR : c; }这段代码里最值得说的是那个\0哨兵。把输入串的结尾补一个不可能出现在正常源码里的字符读取函数就永远不需要判断forward_idx len每次读字符省掉一次比较和一次分支预测失败的可能。输入几十万字符时这点差距是能测出来的。常见的实现思路是文件读进内存后手动追加一个\0或者用 mmap 映射时确认文件尾部之后的那一页是零页。另一个容易忽略的细节是返回值类型。next_char返回int而不是char因为EOF_CHAR需要一个char表达不了的值通常是-1。在 x86 上char默认有符号如果函数返回char读到字节0xFF时会被符号扩展成-1和 EOF 撞车扫描器就会在文件中间莫名其妙地认为输入结束了。这个坑后面第 5 章还会展开说。注意step_back里那个边界检查不是防御性编程而是真的会触发。识别1..2这种畸形输入时很容易出现把指针退到lexeme_begin之前的情况之后整个扫描就乱了。2.2 最长匹配后面那个字符为什么不能急着吃掉词法规则里有一条默认约定几乎所有教材都会提一句但很少讲透最长匹配maximal munch。它的意思是当多条规则都能匹配当前位置的前缀时选匹配长度最长的那个。这条规则听起来理所当然落地时却直接决定了扫描器能不能正确处理、、、-这类多字符运算符。考虑一段关系运算符的识别逻辑如果写成「看到就返回 LT」那么a b会被切成a、、、b语法分析器收到一个孤零零的之后只能报错而真正的错误位置在很前面的地方报错信息会误导使用者。正确做法是先吃掉再看下一个字符是不是/* 识别关系运算符 */ Token scan_relop(Scanner *s) { int c next_char(s); switch (c) { case : if (peek_char(s) ) { next_char(s); return make_token(s, TOK_LE); } if (peek_char(s) ) { next_char(s); return make_token(s, TOK_NE); } return make_token(s, TOK_LT); /* 偷看失败一个字符都不多消费 */ case : if (peek_char(s) ) { next_char(s); return make_token(s, TOK_GE); } return make_token(s, TOK_GT); case : if (peek_char(s) ) { next_char(s); return make_token(s, TOK_EQ); } return make_token(s, TOK_ASSIGN); default: return err_token(s, 无法识别的运算符); } }这里的关键是peek_char和next_char的分工。peek_char只读不消费判断成立之后才用next_char真正吃掉那个字符。如果偷看失败指针原地不动下一个 Token 的起点自然就落在正确的位置上。这就是「前瞻一个字符」在代码里的样子——它不需要任何回退因为压根就没往前走。真正的回退发生在更复杂的场景。比如某门课的实验要求支持右移赋值扫描之后要看两个字符先看是不是是的话再看是不是。如果第二个判断失败就得回退一个字符把已经吃掉的吐出来让它成为下一个 Token 的一部分。三步判断加两次回退代码就开始难看了这也是为什么很多人宁愿把运算符表写成一个switch里的嵌套if。2.3 回退的代价为什么正则引擎会退化成指数级而 DFA 不会手写扫描器里回退一个字符是常数时间代价可以忽略。但如果把「匹配失败就回退重试」这个思路推广到通用的正则匹配问题就来了。经典例子是模式a*a*a*...a*n 个a*去匹配aaaa...an 个a后面跟一个b每个a*都可以选择吃掉不同数量的a失败之后回溯的组合数是指数级的。血泪经验是很多文本编辑器早期版本在超长行上卡死根子就在这种回溯式匹配。词法分析器之所以不受这个问题的困扰是因为它面对的不是任意正则表达式而是「每个 Token 一条规则、所有规则互不重叠到需要复杂回溯」这个受限场景。更本质的原因是正规语言regular language一定可以被某个 DFA 在不需要任何回退的情况下识别——DFA 的每一步都只依赖当前状态和当前字符读到什么就转到什么状态压根不存在「先走一步看看不行再退回来」的概念。最长匹配在 DFA 上的实现方式是一直走到「下一步会进入死状态」为止然后记录最后一次经过的接受状态把指针退回到那个位置。这次回退最多一次且回退距离等于最后一个 Token 之后多读的字符数在词法规则下这个数通常不超过 2。所以两条路线的分野很清楚手写扫描器靠人肉编码来保证「最多回退一两个字符」DFA 靠自动机构造从数学上保证「只需要一次回退」。前者灵活、好调试、错误信息容易做后者正确性有保证、不怕规则复杂但生成的代码像天书。第 6 章还会回到这个取舍上。3. 正则表达式到 DFA子集构造法到底在构造什么如果实验要求从规则文件自动生成扫描器那大概率绕不开 Thompson 构造 子集构造这条链路。很多人在这个环节是靠背步骤过关的先给每个正则加 ε 边连成一整个 NFA再求 ε-闭包再对字母表做 move最后填表。做完之后能跑但说不清每一步到底在干什么。这一章把「子集构造」这个名字拆开看——它构造的不是状态而是状态的集合。3.1 Thompson 构造把一条正则拆成一堆带 ε 边的状态Thompson 构造的规则非常机械每个正则算子对应一种小的状态图拼装方式连接就是把两个片段首尾相接选择就是加一个新的分叉起点和汇合终点闭包就是把片段的首尾连起来并在中间加一条 ε 边跳过整个片段。拼完之后得到一个 NFA它有明确的起点和唯一的接受状态中间挂着一堆不消耗任何字符的 ε 转移。ε 边的存在让 NFA 变得「不确定」站在某个状态上不读任何字符就能跳到另外几个状态。这种不确定性对人来说很直观「这里可能是标识符的开头也可能是关键字的开头」对机器来说却很麻烦因为要模拟它就得同时跟踪一组状态。这就是为什么需要下一步。值得一提的是所有词法规则拼在一起的方式给每条规则单独构造一个 NFA 片段然后加一个新的全局起点用 ε 边连到每个片段的起点。这样多个 Token 的识别就变成了「在一个大 NFA 里跑看最后停在哪条规则的接受状态上」。但这里有个陷阱——最长匹配要求记录的是最后一次经过接受状态的位置而不是第一次。第一次进入接受状态就返回if和ifx就分不清了。3.2 子集构造DFA 的每个状态其实是一组 NFA 状态子集构造的思想一句话能说完NFA 在读完某个前缀后可能处在哪些状态的集合就是 DFA 的一个状态。因为 NFA 的状态数有限所以可能的集合数也有限最多 2^n 个DFA 一定能建出来。# 子集构造从起始状态的 ε-闭包出发BFS 把所有可达的 DFA 状态挖出来 def subset_construction(nfa, start, rules): d0 epsilon_closure({start}) # 起始状态必须先做 ε-闭包 dfa_id {frozenset(d0): 0} # 用 frozenset 当 key因为它可哈希 worklist [frozenset(d0)] trans {} # (dfa_state, char) - dfa_state accepts {} # dfa_state - 命中的规则编号 while worklist: s worklist.pop() for ch in alphabet(nfa): # 按字符类而不是按字符遍历见 3.3 t epsilon_closure(move(s, ch)) # 先走一步再闭包 if not t: # 空集相当于死状态直接不建 continue key frozenset(t) if key not in dfa_id: dfa_id[key] len(dfa_id) worklist.append(key) trans[(dfa_id[s], ch)] dfa_id[key] # 只要集合里含有某条规则的接受状态这个 DFA 状态就是接受状态 hit [r for r in rules if r.accept in s] if hit: accepts[dfa_id[s]] min(hit, keylambda r: r.priority) return dfa_id, trans, accepts几个参数值得说清楚。epsilon_closure求的是一个状态集合在 ε 边上能到达的全部状态实现上就是一个栈式 DFS。move(s, ch)求的是集合s里所有状态读入ch之后能到达的状态不含 ε然后再做一次闭包。if not t: continue那句是优化也是简化——空集意味着「从这组状态出发读这个字符必死」既然必死就不用建这个状态查表时找不到对应项就当错误处理。accepts里的priority解决的是规则重叠问题if既是关键字规则的接受串也是标识符规则的接受串得靠规则顺序决定谁赢。子集构造的理论最坏复杂度是 2 的 n 次方但这个词法分析领域几乎不会踩到。原因很实际词法规则之间高度不重叠绝大多数 Token 的首字符就决定了它属于哪条规则所以实际建出来的 DFA 状态数通常只有几十个和手写的状态机规模差不多。3.3 状态表的落地字符类、默认状态和表压缩DFA 建好之后要变成代码里的数据结构。最直接的是二维数组trans[state][char]如果字母表按 128 个 ASCII 字符算、状态 60 个那就是 7680 个表项一个int16数组不过 15KB完全不用优化。真要压有三种常见做法。第一种是字符等价类。扫描一遍所有状态的出边把「在所有状态下的转移目标都相同」的字符合并成一类。词法分析器里这个压缩比很夸张26 个字母加下划线、10 个数字往往能合并成几个类128 列直接掉到十几列。第二种是默认状态把大部分状态里转移目标都是「错误」的那些项省掉查表时先查一个稀疏表查不到就跳到默认状态。第三种是行位移压缩把二维表压成一维用base[state] char去查适用于状态多、每行非空项少的情况。提示如果实验要求不高别急着做表压缩。一个 128×60 的二维int数组既好调试又能直接打印出来看压缩之后出问题反而难查。压缩是性能优化不是正确性需求。另一个容易被忽略的设计点是关键字通常不进 DFA。把if、while这些串单独建成 NFA 分支会让 DFA 的状态数暴涨而且每加一个关键字就要重新生成一遍表。更常见的做法是让 DFA 只识别id识别完之后拿这个词去关键字表里查一次查到就改 Token 类型查不到就是普通标识符。这个「先当标识符、再查表」的两段式是词法分析里最经典的设计取舍之一。4. 手写扫描器的源码结构一个 while switch 能扛住什么真实工程里纯手写的扫描器比自动生成的多得多。原因不复杂手写的好调试、错误信息能写到具体字符、加特例比如预处理指令、原始字符串字面量时不用回头改语法文件。这一章按一个完整的手写扫描器的结构走一遍从主循环到关键字查表再到数字字面量。4.1 主循环空白、注释、错误三条支路主循环的职责就一个返回下一个有意义的 Token。所以它得先把所有「不产生 Token 的东西」吃掉——空格、制表符、换行、两种注释——然后才进入真正的识别逻辑。/* 扫描主循环跳空白和注释然后分派到具体的识别函数 */ Token *next_token(Scanner *s) { for (;;) { skip_whitespace(s); /* 空格 \t \r \n顺带维护 line / column */ if (s-input[s-pos] / s-input[s-pos 1] /) { skip_line_comment(s); /* 一直吃到 \n 或 EOF注意 EOF 要单独处理 */ continue; } if (s-input[s-pos] / s-input[s-pos 1] *) { skip_block_comment(s); /* 内部自己处理未闭合的情况 */ continue; } break; /* 剩下的就是 Token 起点了 */ } lexeme_begin s-pos; s-tok_line s-line; s-tok_col s-column; /* 记下起点位置报错时要用 */ if (s-pos s-len) return make_token(s, TOK_EOF); int c peek_char(s); if (is_alpha(c) || c _) return scan_ident_or_keyword(s); if (is_digit(c)) return scan_number(s); if (c ) return scan_string_literal(s); if (c \) return scan_char_literal(s); return scan_operator_or_punct(s); }for (;;)加continue的结构比while (has_token)之类的写法好在哪好在它把「跳过无关内容」和「识别 Token」这两件事在控制流上分开了。跳过阶段可能连续遇到空白、行注释、块注释、再空白、再注释continue让这个循环自然成立不需要在外层再套一层。而break之后的部分只在确定「当前位置确实是一个 Token 的开头」时才执行。skip_block_comment是这段代码里最容易写错的地方因为它涉及两条错误路径一是遇到 EOF 还没找到*/说明注释没闭合二是注释内部出现了/*有些语言允许嵌套有些不允。前者必须把起始行号带进错误信息否则使用者根本不知道去哪找后者取决于语言规范但无论选哪种都要写进文档不能靠猜。行号和列号的维护是另一个高频翻车点。skip_whitespace里遇到\n要把line加一、column归零遇到\t要不要按 8 列算、遇到\r\n是两个字符还是一个这些细节不写清楚报错时给出的列号就会整体偏移。常见的实现思路是先做一次输入归一化把\r\n和单独的\r全换成\n之后所有逻辑只面对一种换行符省心很多。4.2 标识符与关键字为什么关键字要查表而不是进 DFA标识符的识别本身很简单首字符是字母或下划线后续字符是字母、数字或下划线。真正有设计空间的是「识别完之后怎么判断它是不是关键字」。三种常见实现哈希表、排序数组二分、字典树。哈希表最通用但需要运行时初始化和处理冲突字典树查得最快且前缀共享但构建代码略多排序数组二分是课程实验里性价比最高的选择——关键字表在编译期就固定了排好序放进一个静态数组运行时零初始化开销。/* 关键字表按字典序排好二分查找静态数组零运行时初始化 */ static const char *const KEYWORDS[] { break, case, char, const, continue, default, do, double, else, enum, extern, float, for, goto, if, int, long, register, return, short, signed, sizeof, static, struct, switch, typedef, union, unsigned, void, volatile, while }; /* 只比较前 len 个字符且要求表项长度恰好等于 len避免 ifx 命中 if */ TokenType lookup_keyword(const char *s, int len) { int lo 0, hi (int)(sizeof(KEYWORDS) / sizeof(KEYWORDS[0])) - 1; while (lo hi) { int mid (lo hi) / 2; int cmp strncmp(s, KEYWORDS[mid], (size_t)len); if (cmp 0) { if (KEYWORDS[mid][len] \0) return TOK_KW_BASE mid; /* 长度也对上 */ cmp -1; /* 表项更长说明当前串字典序更小 */ } if (cmp 0) hi mid - 1; else lo mid 1; } return TOK_ID; /* 表里没有就是普通标识符 */ }这段代码里最关键的不是二分而是KEYWORDS[mid][len] \0这个判断。只做strncmp的话识别出if之后去查表strncmp(ifx, if, 3)会读越界就算用len限定了比较长度ifx的前两个字符也和if完全相等会被误判成关键字。加上长度恰好相等的检查才安全。另一种做法是把关键字和标识符统一交给符号表。符号表初始化时把关键字以「预置条目」的形式插进去查表接口只有一个find(s)返回非空就说明是关键字返回空就新建一个标识符条目。这种设计的好处是后面语法分析、语义分析都能复用同一个符号表接口坏处是符号表的实现质量会直接拖累词法分析的性能——每识别一个标识符都要做一次哈希和内存分配。注意标识符的长度上限要定死。很多实验实现里用一个固定大小的缓冲区存当前单词超出长度就截断结果两个长标识符被当成同一个报错信息还显示成截断后的样子排查起来非常痛苦。4.3 数字字面量状态机写法与边界条件数字是词法分析里边界条件最多的 Token。整数、定点小数、科学计数法、十六进制、八进制、各种后缀每种都有自己的合法形式还要处理一堆畸形输入。/* 数字扫描一次走完整个字面量即使出错也要把整个串吃掉再报错 */ Token scan_number(Scanner *s) { int is_float 0; if (peek_char(s) 0 (s-input[s-pos 1] x || s-input[s-pos 1] X)) { advance(s); advance(s); /* 吃掉 0x */ if (!is_hex(peek_char(s))) return err_token(s, 0x 后缺少十六进制数字); while (is_hex(peek_char(s))) advance(s); return make_token(s, TOK_INT); } while (is_digit(peek_char(s))) advance(s); if (peek_char(s) .) { /* 小数点必须跟数字或前面已有数字 */ is_float 1; advance(s); while (is_digit(peek_char(s))) advance(s); } if (peek_char(s) e || peek_char(s) E) { is_float 1; advance(s); if (peek_char(s) || peek_char(s) -) advance(s); if (!is_digit(peek_char(s))) return err_token(s, 指数部分缺少数字); while (is_digit(peek_char(s))) advance(s); } return make_token(s, is_float ? TOK_FLOAT : TOK_INT); }这段代码的写法有个统一原则出错时也要把整个字面量消费掉。如果1e在报完错之后指针停在e上下一轮扫描会把e当成一个标识符再后面可能又触发一堆莫名其妙的错误错误信息从一条变成五条真正的问题反而被淹没。一次性把整个畸形串吃掉错误数量就等于问题数量这是编译器错误恢复里最基本的策略。还有一个容易忽略的细节.5这种写法在 C 里是合法的等价于0.5但代码里scan_number的入口条件是is_digit(peek_char(s)).开头的根本进不来。要么在分派逻辑里判断「.后面跟数字」也走数字扫描要么明确不支持这种写法并在文档里写清楚。两种都行但必须有意识地做决定不能靠碰巧。5. 避坑与排查词法分析器最容易翻车的五个地方前四章讲的是设计这一章讲的是实际写代码时会撞上的东西。这五个问题有个共同点现象看起来像别的地方出了问题排查半天才发现根子在扫描器。5.1 字符与缓冲区层面的三个坑现象一源文件最后一行没有换行符时最后一个 Token 丢了或者程序直接死循环。原因通常出在循环条件上。如果跳过空白的逻辑写成while (cur ! \n) advance();那读到文件结尾时既不会遇到\n也不会自然退出advance一直往后读读到内存里随机的内容才停另一种实现是用\n作为 Token 的分隔依据最后一行没有\n最后一个 Token 就一直处于「未完成」状态函数返回时没被交出去。解决办法是彻底把 EOF 当成一种普通字符来处理输入缓冲区末尾补\0next_char读到它就返回EOF_CHAR所有循环条件统一写成while (peek_char(s) ! EOF_CHAR !is_terminator(peek_char(s)))。所有「读到某个字符为止」的逻辑都必须显式包含 EOF 分支这是写扫描器时的第一条纪律。现象二在 Windows 上运行报错行号是实际行号的两倍或者块注释之后的所有代码都不见了。原因是\r\n被当成两个换行。skip_whitespace里遇到\r加一次行号遇到\n又加一次或者行注释的结束条件写成「读到\r为止」结果\r之后剩下的\n被当成一个空行继续留在流里行号统计就整体偏移了。更隐蔽的一种情况出现在字符串字面量里abc\r\n这种跨行字符串扫描逻辑只认\n\r被当成普通字符塞进字面量里最后字符串常量的实际内容和预期差一个字节。解决办法是在读文件之后立刻做一次归一化把所有\r\n和孤立的\r都替换成\n并在文档里注明行号统计基于归一化之后的文本。现象三在某些输入上扫描结果完全正确换一个文件就开始把标识符识别错甚至触发 EOF。这类问题的经典根源是char的有符号性。EOF在标准库里定义为-1如果扫描函数签名写成char next_char()读到字节0xFF时会被符号扩展成-1和EOF完全一样扫描器就会在文件中间错误地宣布输入结束。UTF-8 编码的中文字符里有大量0x80以上的字节所以在源码里写中文注释或者中文字符串这个 bug 迟早会暴露。解决办法是全链路用int存字符next_char返回int缓冲区指针用unsigned char *读比较之前先转成unsigned char。这条经验几乎每个写过 C 语言文本处理的人都有过一次代价通常是一整个下午。5.2 规则与状态层面的两个坑现象四输入1.2.3时编译器吐出五条错误第二条开始全是「意外的符号.」。原因就是 4.3 节说的那个问题数字扫描遇到第二个.时提前返回了指针停在第二个.上下一轮扫描把它识别成一个独立的标点 Token语法分析器收到INT DOT INT DOT INT这样的序列自然一脸懵。解决办法是让数字扫描的错误路径负责「吃掉整个字面量」从当前起点开始只要后续字符可能是数字字面量的一部分数字、.、字母、/-指数符号就继续消费直到遇到明确的终止符为止然后再一次性报错。这个策略在编译器前端叫 panic mode 恢复词法层的实现比语法层简单得多但效果很明显。现象五ab被切成了ab和预期不一致或者块注释/* ... */里再出现/*时行为诡异。前者是最长匹配方向搞反了的典型症状。正确的切法是ab从a之后的位置开始和都能匹配取长的剩下的b里再取。如果实现里写成「先试单字符再试双字符成功就返回」就会得到这个错误切分。正规做法是有序地尝试所有可能的长度从最长往最短试第一个成功的就采用。后者涉及注释的嵌套语义C 系语言不允许嵌套所以扫描到第一个*/就结束注释内部的/*是普通内容。但如果实现里用了递归或者栈来处理注释就可能出现嵌嵌套行为和语言规范不符。解决办法是把注释扫描写成一个简单的线性循环遇到*/立刻退出中途什么都不记。6. 设计取舍手写还是生成以及怎么验证一个扫描器是对的走到这里前面所有机制都可以归结到一个选择上扫描器是手写还是用规则文件生成。维度手写扫描器规则文件 生成器起步成本低一个while加switch就能跑中要先写规则、跑生成器、再接生成代码加新 Token改代码可能要动主循环改规则文件重新生成错误信息可以精确到字符能写任意提示语只能报「无法匹配」需要额外映射表性能可控能针对热点手写优化通常更快表驱动没有分支预测失败可调试性高设断点就能看状态低生成出来的代码基本没法读规则复杂时容易写成一大坨嵌套if状态数自动膨胀但正确性有保证非 ASCII 支持自己处理编码转换取决于生成器的字母表定义这张表最能说明问题的一行是「错误信息」。真实语言的编译器里用户看到的报错质量很大一部分由扫描器决定是「第 12 行第 8 列附近有一个无法识别的字符」还是「lex error at offset 4213」体验差距巨大。生成器路线要做到同样的效果得在自动机外面再套一层「死状态 → 具体错误消息」的映射映射本身的维护成本往往超过手写的收益。但手写也有明显的天花板。规则一复杂嵌套if就开始互相干扰改一个 Token 的识别逻辑可能影响到三个不相干的地方。血泪经验是手写扫描器一旦超过三百行就该考虑把规则形式化哪怕不真的跑生成器也要先写出规则表再照表实现。验证方法这块我习惯先做一件很土的事写一个 token dump 工具把源文件喂进去输出(类型, 词元文本, 行, 列)四元组然后拿几个精心构造的输入去跑。这些输入应该覆盖几类边界只有空白和注释的文件、最后一行没换行的文件、含\r\n的文件、所有多字符运算符连写!、数字的畸形写法1.2.3、1e、0x、超长标识符、注释未闭合。每类输入的预期输出都是人肉核对的对不上就说明扫描器有问题——这种测试比任何单元测试框架都直接因为它输出的就是 Token 流本身没有任何抽象层可以藏 bug。第二个验证手段是可逆性检查。对大多数语言来说把 token dump 里所有词元文本按顺序拼起来应该等于原文件去掉空白和注释之后的内容。这个性质能一次性抓出一大类问题漏掉字符、重复消费字符、回退过头。实现起来也不难扫描器跑两遍一遍出 Token 流一遍出「去掉空白注释的原文件」两个字符串比对。这个检查在字符编码出问题时特别有效因为漏掉一个字节在单看 Token 流时根本看不出来。第三个是差分测试。如果目标语言已经有一个成熟的开源实现就把同一批源文件分别喂给两个扫描器比较 Token 序列。不一致的地方有两种可能要么自己的实现有 bug要么那个实现对规范的解读不同两种都值得深挖。这种做法在课程实验里可能没有现成的参考实现但如果有收益极高。从那以后我每次写扫描器都会先把 token dump 的断言写出来再写扫描逻辑先定义清楚「这段输入应该产出哪几个 Token、每个的行列号是多少」再去实现。这个顺序反过来做就会变成「先写一堆if跑一遍发现能出 Token就认为对了」然后在校验阶段被一个\r\n或者一个1e打回原形。这份课程实验的资源可以当对照本来用先看它的主循环怎么组织、空白和注释怎么跳、关键字查表用的是什么结构再拿上面那几组边界输入去跑一遍看它的 Token 流和你预期的是否一致——读别人的扫描器代码比读任何教材上的自动机理论都更能建立起对词法分析的直觉。希望帮到你。本文还有配套的精品资源点击获取