企业官网建设流程全解析

1. NFA和DFA是什么

编译原理进行到词法分析阶段，逃不开两个概念：NFA与DFA。简单说，它们都是用来描述词法规则的形式化工具，但二者的“性格”差别极大。DFA全称是确定性有限自动机，一个状态在遇到一个输入符号时，下一跳是唯一确定的，处理起来非常直白；NFA全称是非确定性有限自动机，同一状态下同一个输入符号可能跳到多个状态，还可能存在不需要任何输入就能跳转的ε转移，执行逻辑上天然带“分叉”。

这个不确定性带来一个现实问题：如果拿NFA直接做词法分析器，每读一个字符可能要沿着多路分支去尝试，匹配效率完全不可控。因此，实际工程里几乎不可能直接拿NFA去跑词法分析，而是先构造NFA，再把它转换成等价的DFA，让每条路径唯一化。等价的含义是两者识别的语言完全一致，即能接受的正规式集合完全相同，只是DFA的每个状态变成了原来NFA的一个状态集合，这个集合被称为“子集”。

从正规式到DFA的完整链路是这样的：先把正规式解析成一棵语法树，再从语法树构造NFA，然后通过子集构造算法把NFA转为DFA，最后做DFA的最小化压缩。这个流水线里，NFA本身不直接面对输入串，它是中间产物，承上启下。很多人初次学到这里觉得绕，是因为没有站在“编译器到底怎么用这几个东西”的角度去理解。词法分析器的目标其实只有一个：给定一个输入字符串，快速判断它属于哪个token类型（比如标识符、关键字、数字、运算符），并输出token流。NFA和DFA就是用来承载这个判断逻辑的自动机模型。

我给初学者的建议是：先抛开教科书里的证明细节，把NFA和DFA想象成两套“状态转移图”。NFA像是一张可以走岔路、甚至凭空跳转的地图，DFA则是每条路都笔直、每个路口只有一条出口的公路网。这两套图描述的是同一种语言，只是表达方式不同，DFA更适合机跑，NFA更适合人写规则。理解了这一点，后面再看子集构造、最小化这些操作，就是在讲“怎么把岔路图改成单行道公路网，然后顺手把冗余路段删掉”。

2. 为什么要先构造NFA再转DFA，不直接生成DFA

2.1 正规式到NFA的构造是“翻译”不是“设计”

接触过正则表达式的人都能感受到，写一个正则容易，但要直接从正则推导出一个DFA的状态转移表，思维负担非常大。因为DFA要求每个状态下每个输入符号都有且仅有一个转移目标，但人在写规则时习惯用并集、可选、重复这些灵活的语义，这些语义几乎天然就是NFA式的。比如a|b，人读起来是“要么a要么b”，而转化成自动机就是两条平行的路径，这就是一个标准NFA结构。再比如a*，表示零个或多个a，在NFA里体现为一条从终态回到初态的ε回边。这种结构如果直接设计DFA，光是把复杂的嵌套语义拆解成无歧义的单一路径就够折腾一阵子了。

所以正规式到NFA的构造方法（比如Thompson构造法）本质上是机械化的“翻译”步骤。它把每个正规式子结构对应成一个小子图，再通过ε转移把这些子图拼成一个完整的NFA。这个过程不需要思考优化，完全是按语法结构递归搭积木。四个基本结构的拼法如下：连接就是首尾相接；并集就是引入一个新开始状态，分别用ε跳转到两个子图；闭包就是在新子图外面包一层ε回边；单个字符就是两个状态之间连一条标着该字符的边。

这里有个实用经验：写正规式时把结构拆成“字符、连接、并集、闭包”四种原子操作，心里就有一本“翻译手册”，直接照着拼NFA比苦想DFA省力得多。而且Thompson构造法有个很好的性质——每个新增状态至多有两出边，整个NFA状态数和边数与正规式长度线性相关，不会爆炸，这为后续子集构造提供了健康的输入。

2.2 NFA更能保留正则语义的可读性

从可维护性的角度说，NFA也更贴近人的思维模型。一段正规式如果直接转成DFA，状态转移表可能面目全非，很难回溯“这到底对应原正则的哪一段语义”。而NFA的子图结构和正规式基本是一一对应的，开发者排查问题时可以拿着NFA图对照原正则去检查，哪里多了一条边、哪里少了一个状态一目了然。

我实际做过一个词法分析器，里面有几十个token规则，维护时最怕的就是某个状态跳错了。如果直接维护DFA表，改一个规则可能要连带改好几个状态。但如果保留NFA作为源模型，改完正则重新跑一遍转换流程，DFA自动更新，人就省心了。这也是很多词法分析器生成器（比如lex家族的实现思路）内部的工作原理：源文件写正则，生成器内部构建NFA，再统一转成DFA用于匹配。用户看到的接口是正则，内部跑的是压缩后的状态机，分工清晰。

有意思的是，还有一类工具（比如部分正则引擎）会反其道而行，直接用优化过的NFA做匹配，利用回溯或并行模拟来处理不确定性。但这类方案适用场景有限，处理简单的词法规则时性能可能不错，一旦规则多、输入长，回溯代价就很难控。主流编译器的词法分析器，仍然是“NFA构型、DFA执行”这条稳妥路线。

2.3 子集构造的“集合语义”能天然处理歧义

NFA转DFA的核心算法叫子集构造（subset construction），思路是把NFA上某个状态在某个输入符号下能抵达的所有状态“打包”成DFA的一个新状态。这个打包动作天然处理了NFA的不确定性：多个可能的分支在DFA层面被合并成一个明确的集合，不会再出现“同一输入走两条路”的问题。

从词法分析角度想，这种集合语义还有一个额外的好处：真正匹配token时，如果NFA中存在多个可接受路径（比如某个前缀既能被认成关键字又能被认成标识符），压缩成DFA后，状态里会同时包含多个接受态，我们可以在这些接受态之间定义优先级，比如“关键字优先于标识符”。这个处理手法在后续章节讲词法歧义消除时会反复遇到，也是工程师必须掌握的实战技巧。

所以，先NFA后DFA并不是“绕远路”，而是把“人的表达”和“机器的执行”之间的鸿沟，用两个各擅其场的中间层给填平了。一条从正则到状态机的工程流水线，每个环节都有明确的职责，缺一则另一侧的工作会变得异常吃力。

3. 核心实操：NFA转DFA的子集构造全过程

3.1 ε闭包(move)和子集构造的基本运算

子集构造依赖两个基本函数：ε闭包（ε-closure）和move。理解透这两个函数，整个算法就稳了一半。

ε闭包的定义是：从一个状态集合T出发，沿着所有ε边能到达的状态，统统并进来，包括T自身。它的作用是把“不消耗任何字符就能发生的跳转”全部吸收进当前集合。比如某个NFA状态s有一条ε边指向t，t又有一条ε边指向u，那么closure({s}) = {s, t, u}。这个闭包计算的实现通常用栈或队列做图的深度/广度遍历，代码量很小。

move函数的定义是：从状态集合T出发，消耗一个输入符号c，所有能到达的状态的集合。注意move不做ε扩展，它只找出“直接吃下c字符的下一跳”。实际操作时，标准的顺序是：先根据当前状态集合计算move(T, c)，得到下一跳集合，再对这个集合求ε闭包，两者合并就是D状态在输入c下跳转的目标状态。

我以前入门时写代码容易搞错一个顺序：先求闭包再move。这么做会把ε边跨过字符边，导致本该等一个具体字符的地方被空跳偷跑了。严谨的步骤永远是“先move后closure”。当然，如果整个NFA压根没有ε边，那么这个顺序问题就不存在，但正规式构造出的NFA几乎不可能没有ε边，所以这个坑得非常留意。

3.2 一个实例：能识别“a|b*c”的NFA如何转DFA

我们用一个小例子完整走一遍，这样比干背算法步骤要有感觉得多。假设要识别的正规式是 a|b*c。按Thompson构造法，先分别构造a子图、b子图和c子图，再用并集和连接把它们拼起来。得到的NFA大致有7个状态。为方便叙述，设：

• 开始状态 S0
• 经过ε可跳到 a 子图的开始，也可跳到 b* 子图的开始
• b* 子图内部：S1（b循环）、S2（可ε跳到c子图开始）
• a 子图：从S3吃a到S4
• c 子图：从S5吃c到S6（S6为最终接受态，同时整个NFA最终状态也由此汇合）

现在开始子集构造。先计算closure({S0})，把所有从S0出发的ε边走一遍，得到的集合包含{S0, S1, S3, S5}，记作D0。这还没完，S1后面有到S2的ε边，S2又是到S5的ε跳板，但S2本身也要进集合，所以再扩一轮，closure({S0})实际为{S0, S1, S2, S3, S5}。初学者经常在这里漏算S2，导致后面状态数不对。

看一下输入符号a：从D0中各状态出发，吃a能到的地方只有S3的a边，目标是S4，于是move(D0, a)={S4}，再求closure({S4})，没有ε边，结果就是D1={S4}。D1是接受态吗？不是，因为S4不是终态，终态是S6。

再看输入符号b：D0里S1有b回边，吃b后回到S1，所以move(D0, b)={S1}，再做closure得到{S1, S2, S5}，记为D2。这个集合里的S5是c子图的开始，但此时还没吃c，所以不能被误判为接受态。很多初学的人看到S5附近有路就以为能接受，这不对，必须吃到c到S6才算接受。

再算输入符号c：D0中S2有ε到S5、S5吃c到S6，注意移动过程是从S2没吃任何字符就到S5，再由S5吃c到S6，所以move(D0, c)={S6}，closure后还是{S6}，记为D3，D3是接受态。

接着对D2按同样的方式计算：吃b回到S1再closure回D2自己，形成一条回边；吃c则从S2/S5走c边到达S6，得到D3。最终这个DFA只有四个状态，状态转移关系如下：

对比NFA转DFA前后的差异：NFA在S0处眼见着有去a、b、c三条“候选道路”，执行时必须都试一遍；DFA的D0遇到这几个字符则各走各的唯一出口，完全确定。这就是“编译”带来的效率提升。

3.3 实操中的状态标记和终止条件

真正实现子集构造时，要维护一张“状态对应表”，记录D状态编号和它对应的NFA状态集合。算法开始时初始化一个队列，把closure({NFA开始状态})塞进去作为第一个D状态；然后循环取出队列头的D状态，逐个对字母表中的每个符号执行move与closure，如果得到的新集合从未出现，就新创建一个DFA状态，记录转移边，并把它加入队列；如果已经出现过，则只补记一条转移边，不再重复创建。

终止条件是队列为空，意味着所有可达DFA状态都已经被“展开”过一遍。很多人问，会不会出现无限循环？不会，因为NFA状态数量有限，D状态集合又是NFA状态集合的子集，最多只有2的n次方种组合（n为NFA状态数），扩张一定会在有限步内停。实际运算时，由于正规式结构约束，状态数通常远小于这个上界，不必太紧张。

还有一个容易被忽略的细节：哪些DFA状态是接受态？规则是凡DFA状态对应的NFA状态集合里包含原NFA的接受态，该DFA状态就是接受态。比如前面的D3集合包含S6，所以D3是接受态。如果原NFA有多个接受态，那么只要集合里出现任意一个，这个DFA状态就接受。

提示：子集构造结果里，可能出现“带接受态但不是最终输入结束状态”的情况，例如集合既包含某token的终态、又能继续通过字符走到别的状态，这在词法分析中叫“最长匹配”问题。后续章节讲词法规则优先级时，这种状态会被特别处理，一般通过记录最近一次接受的输入位置来解决。

4. DFA最小化：把状态机压缩到最精简

4.1 为什么要做最小化，压缩带来什么收益

子集构造得到的DFA往往不是最小的，里面可能存在大量行为等价的状态。两个状态如果从任意输入串出发，要么都接受、要么都拒绝，且分别到达的下一状态也互为等价，那么它们可以被合并成一个状态。这个合并过程就是DFA最小化（也称化简），最经典的实现手段是Hopcroft算法（也是一个划分细化算法，因效率高被广泛使用）或教科书上更常见的Moore划分法。

最小化的收益有两层：第一是节省存储空间，状态少了，转移表就小。词法分析器通常常驻内存、每次编译都要加载，状态数从几百压到几十，直接减少内存占用。第二是加快匹配速度，虽然DFA每个状态单次跳转已经是O(1)，但状态多了会放大缓存miss概率，减少状态数对实际运行时间也有微弱但可测的改善。

这里有个容易混淆的概念：最小化只压缩等价状态，绝不改变DFA所识别的语言。也就是说，最小化前后的DFA接收的字符串集合完全相同，只是地图上少了几条重复路段。这和子集构造不同，子集构造是在改变自动机形态，最小化是在删冗余。

4.2 划分法的运作流程：从接受态开始逆推

划分法的直观思路是：先把所有状态分成两组，接受态一组、非接受态一组。这两个集合显然是可区分的（一个接受空串一个不接受），后续再逐步细化。细化规则是：如果两个状态在同一个组里，但它们在某个输入符号c下跳转到的状态属于不同的组，那么这两个状态必须分开。不断重复“按转移目标划分”的过程，直到没有状态组能被进一步细分。

以前面得到的四状态DFA为例。全体状态先划分为两个组：G1={D0, D1, D2}（非接受），G2={D3}（接受）。看G1内部：D1在所有输入上都无转移（按正规式语义，D1吃不到任何继续前进的字符，也没有接受标记），这跟D0、D2显然不同。D0吃a去D1、吃b去D2、吃c去D3；D2吃b回自己、吃c去D3，不收a。按字母表逐符号比对：

• D0和D2在字母a上的行为不同（D0有a边，D2没有），且a边的目标D1属于非接受组，与D2“无转移”不同，所以二者至少应当分开。
• D0和D2再比b、c时，各自跳转目标都在同一大组里，看不出区别，但由于a行为已经不同，划分时就会把它们拆开。

这里多说一句，等价的定义严格按“是否区分”来。如果存在任意输入串能区分两个状态，它们绝不等价，必须分开。最终划分结果为 {D0}、{D1}、{D2}、{D3}，恰好四组，前面这个例子本身已经是最小DFA。现实中很多未化简的DFA会有几十上百个状态被合并到只有几位数的核心状态，那个压缩量才明显。

4.3 一个常被忽视的技巧：处理死状态

工程里还有一个和最小化配套的优化，叫“死状态合并”。死状态是指一个DFA状态，一旦进入就永远不可能到达任何接受态了。更直白地讲，它就是一个词法匹配中的黑洞——吃再多字符也不会成功。子集构造生成的DFA里经常有这种状态，它们在转移表中占据大量行和列，但实际完全没用。

正规式的DFA中，遇到一个当前token不接受的字符时，分析器会回到上一次接受的位置重新开始匹配，根本不会踏进这些死状态。因此，把死状态统一合并成一个“非接受且所有输入符号都回指自己”的状态，可以让转移表更紧凑。这不属于DFA最小化的核心定义，但实际做词法生成器时几乎是必做的后处理步骤。

我自己的实践经验是：不要在子集构造过程中频繁检查死状态，这会拖慢算法；等子集构造完毕，再一次性做死状态合并和划分法最小化，代码逻辑清晰且不容易出bug。先后顺序对了，很多边界问题会自动消失。

5. 动手实现一个简化版词法分析器

5.1 数据结构与接口设计

用Python实现一个能跑通“正规式→NFA→DFA→最小化→匹配单词”的小工具，是理解这套流程的最佳路径。整个代码无需太长，几百行内足够，但数据结构必须设计清楚。

我习惯把NFA表示为：状态用整型编号，边的集合用三元组（源状态、输入字符、目标状态）表示，其中输入字符为None时表示ε边。开始状态记录为start，接受状态集合记录为accepts。DFA则用字典保存转移关系，形如transition[(状态, 字符)] = 目标状态，再加一个accepts集合记录哪些编号是接受态。

核心接口只有三个：regex_to_nfa(regex)负责把正则字符串解析成NFA，subset_construction(nfa)执行子集构造返回DFA，minimize_dfa(dfa)执行划分法最小化。再看一个match(dfa, text)函数，输入一个字符串，判断整个串是否被词法器识别，并返回识别的token类型。这三个接口的顺序，就是编译原理词法分析器生成的骨架。

5.2 从正规式到NFA的递归构造

解析正则时，我建议直接用递归下降的方式按结构分解：先处理并集，再处理连接，然后处理闭包，最后处理单个字符。这个顺序符合运算符优先级，也和平时用正则的习惯一致：a|b*先看到的应该是两边的整体a和b*，而不是先把b*拆开。

构造NFA时用四个辅助函数：build_char(c)生成两个状态、一条字符边；build_concat(n1, n2)把两个子图首尾相接；build_union(n1, n2)新建开始与结束状态，用ε边把两个子图并联；build_star(n)新建状态，在子图前后加ε环回。

这里有一点经验，构造时不要图省事跳过“新建统一结束状态”这一步。并联和闭包场景里，如果不把各个子图的接受态统一到一个汇合状态，后续求closure和move时会在接受判定上出各种奇奇怪怪的问题。统一汇合后，整个NFA只有一个开始状态和一个接受状态，子集构造时不必考虑多个终态，逻辑一下子简单很多。

5.3 子集构造与最小化的代码骨架

我列一段子集构造的伪代码骨架，重点展示逻辑顺序。实际的Python实现还要处理字符表枚举、集合转冻结集合用于字典查找这类细节。

def epsilon_closure(states, nfa): stack = list(states) closure = set(states) while stack: s = stack.pop() for edge in nfa.edges_from(s): if edge.symbol is None and edge.target not in closure: closure.add(edge.target) stack.append(edge.target) return frozenset(closure) def move(states, symbol, nfa): result = set() for s in states: for edge in nfa.edges_from(s): if edge.symbol == symbol: result.add(edge.target) return result def subset_construction(nfa, alphabet): start = epsilon_closure({nfa.start}, nfa) dfa_states = [start] state_map = {start: 0} transitions = {} accepts = set() queue = [start] while queue: current = queue.pop(0) i = state_map[current] if any(s in nfa.accepts for s in current): accepts.add(i) for ch in alphabet: nxt = epsilon_closure(move(current, ch, nfa), nfa) if not nxt: continue if nxt not in state_map: state_map[nxt] = len(dfa_states) dfa_states.append(nxt) queue.append(nxt) j = state_map[nxt] transitions[(i, ch)] = j return build_dfa(dfa_states, transitions, accepts)

最小化部分的代码核心是维护一个partition列表，反复扫描每个组内的状态，按照转移目标所在组进行细分。落到实操上，每一步细分后要把当前组拆成若干新组，如果一个组无法再拆就保留。终止条件是遍历完所有组都没有变化。

这里有个实用的工程细节：Python里用字典查转移表时，键写成(状态, 字符)元组虽然方便，但状态多了以后内存翻倍。更好的做法是用嵌套字典：transition[状态][字符] = 目标状态，这样每个状态只维护一条映射，目标状态相同的还能共享。小项目无所谓，但真拿来生成几千状态的词法器，区别很明显。

5.4 用一个小例子走通全流程

我们用“标识符与关键字”这个小场景走一遍。正规式可以是(a|b|c)(a|b|c|0|1)*，即字母开头、后续字母或数字，用来匹配简单的变量名。先手算NFA，再交给代码转换，最后确认很多输入串（比如"a"、"abc1"、"1a"）的接受情况是否符合预期。

用代码跑完子集构造，得到的DFA大概3个状态：开始状态接受空串吗？不接受，因为标识符必须至少一个字母；第二个状态是吃过首字母后到达的状态；第三个状态是吃过数字后的状态（如果首字符是数字则直接走向死状态）。这个结果和手推一致，能帮助我们确认代码路径正确。

跑最小化后，状态数从3变2是可能的，因为“吃完首字母的状态”和“吃完后续字符的状态”在功能上等价——它们都处于“正在匹配标识符”的中间态，后续转移行为完全一样。这种等价状态在全手工构造的状态机里很容易被忽略，但划分法能一眼识破。

6. 常见问题与排查技巧实录

6.1 ε闭包算漏状态，导致匹配结果偏少或偏多

这个坑我见得太多了。初学者写closure时，常常只对直接ε边做一次遍历，忘了ε边后面还可能缀着更长的ε链。结果DFA状态数偏少，某些边界输入串被错误地拒绝或接受。

排查思路很简单：写一个断言函数，对每个正规式生成的NFA，先手工算出closure表，再和代码跑出来的结果逐项比对。如果发现差异，多半是循环退出条件写错了——正确做法是用栈/队列做“不断扩张直到没有新状态加入”的循环，而不是用固定层数的for循环。我给初学者的建议是：closure函数本质就是一个图遍历，务必用visited集合做去重，否则还会陷入死循环。

6.2 子集构造爆状态数，导致内存暴涨

虽然理论上DFA状态数可以到2的n次方，但实际正规式写得不合理时（比如大量嵌套闭包组合），状态数依然可能膨胀到不可接受。这种情况通常不是算法错了，而是正则本身太复杂。

一个实用对策是：词法规则拆分。把八十个token类型当作一个巨大的DFA来构造，往往一不小心就爆。拆成几十个小DFA，每组按优先级排序，依次匹配，状态总量会小很多。代价是要稍多几次匹配尝试，但对大多数语言的词法规则而言，这个损换完全可接受。我自己处理复杂语言时，甚至会按“关键字”、“标识符与字面量”、“运算符与分隔符”三大类分别生成DFA，运行期按token类型分派。

6.3 最小化时把不等价状态错并，导致识别精度下降

最小化算法本身逻辑不复杂，出错往往在实现细节上：比如比较两个状态的转移时，忘记处理“无转移”和“有转移但走向同一组”的差别。严格来说，如果一个状态在符号c上没有转移，另一个走到了某个组，那它们必然不等价，必须分开。许多人的实现里把这个情况当成“都无转移”来对待，就会产生错误合并。

我的建议是，在计算转移目标映射时，给缺少转移的情况返回一个特殊值（比如-1），并在比较映射时把它当作一个独立的组来比较。这样“无转移”和“任何具体组”都截然不同，不可能被错误地并到一起。写完最小化逻辑后，跑一批随机生成的测试串，确认最小化前后的接受结果完全一致，这是一个性价比非常高的验证手段。

6.4 匹配时最长匹配和优先级处理不当

词法分析器在实际分析源码时，必须采用“最长匹配”策略。例如关键字if和标识符ifx，一个词法分析器读到ifx时，绝不能在读完if就停下来把它当关键字，必须继续吃字符直到无法延伸，这时ifx整体才算标识符。自动机本身给出的状态转移并不区分“曾经经过接受态”，所以工程实现上要有额外机制：扫描过程中记录最近一次接受态的位置和状态，遇到死路时回退到该位置做token输出。

这种机制在基于DFA的实现里叫“记忆最近接受点”，实现上只是几个变量的事，但少了它，词法分析器就会把a+b拆成a、+、b期间把a+这种非法前缀的错误都暴露出来，显然是错的。我带的项目里，至少有两位实习同学栽在这个细节上，最后都是靠跑一段包含多义前缀的测试用例才发现。建议大家写完匹配函数后，用一个带“关键字和标识符重叠”的测试集（比如if、iff、if8）做回归测试，立刻就能看出问题。

6.5 工具链中的常见选择与避坑

实际工程里不一定非要自己撸完整套转换代码，很多开源工具已经封装好了。比如flex家族使用正则规则文件生成C语言的词法分析器，内部早已实现NFA转DFA和最小化。用这类工具时，最常踩的坑反而是书写规则时的优先级和状态管理。心里有了NFA/DFA这套底子，写flex规则时会自然去想“这一条规则和另一条规则在什么输入前缀上会撞车”，提前就能调整规则的排列顺序。

如果要自己实现教学用的工具，我建议别一上来就抄lex语法，先用纯Python写一个极简版本跑通主流程。代码量不大，遇到问题时便于调试和可视化。等主流程跑通，再逐渐扩展成真正的模板生成器。把式样和实现拆分清楚，整个项目就不会被工具链的复杂度带偏。

提示：自己实现时，表达NFA时尽量用轻量对象或元组，避免过早引入类层次。状态和边的表示一旦复杂化，调试成本会成倍上升。宁可写着“不入流”但直白的数据结构，先把流程跑通，再做面向对象的封装。

最后再分享一点个人心得

编译原理课程学到词法分析，最劝退的地方往往不是概念多，而是概念之间的衔接关系不清晰。NFA和DFA这个环节，如果只是看书上的定义，很容易觉得“不过是个形式化模型而已”，但亲手把一个正规式变成DFA状态表，再看着它匹配真实的字符串，那种“原来编译器是这样认单词”的通透感，完全不是看书能替代的。

我自己当年入门时，是拿一个带几百行规则的真实编程语言做测试，把词法部分彻底跑通之后，才真正理解为什么教科书要花那么多篇幅讲ε闭包和子集构造——因为这在工业级实现里真的每天都要用到。建议初学者别怕在转换算法上多花时间，尽量自己写出完整代码，至少跑通一个包含关键字、标识符、整数和运算符的迷你语言。这套工程量不算大，但对后续的语法分析、中间代码生成等章节，会打下非常扎实的基础。

再做一个小推广：这套“NFA→DFA→最小化”的流程，不仅用于编译器的词法分析器，也被广泛应用在正则表达式引擎、网络协议状态机、文本抽取管线里。把自动机的思路吃透，你在这些领域看问题的视角会完全不同。如果后续有机会，我再写一篇关于词法分析器如何做错误恢复和最长匹配策略的详细文章，这些是生成器文档里最少提到、也恰恰是最影响实际体验的部分。