简介这份压缩包面向编译原理课程实验提供用Java实现的SLR(1)语法分析器适合计算机专业学生和自学者对照课堂内容理解自底向上的语法分析过程并完成实验参考与查漏补缺。代码围绕上下文无关文法处理展开涵盖文法表示、消除左递归与左公因子、FOLLOW集计算、闭包与GOTO集构造、分析表生成以及移进归约解析等环节可帮助读者把抽象概念落到具体实现也能为课程设计中的文法预处理、状态机扩展和解析流程调试提供可借鉴思路。包内共85个文件以76个Java源码为主体另有6个XML配置、项目元数据文件和说明文本压缩包约40KB目录组织便于按模块查阅。已有524人学习适合需要结合源码梳理SLR(1)分析器结构、理解分析表构造细节并排查实验问题的读者。1. 别急着写代码先弄清 SLR(1) 到底在算什么很多人对 SLR(1) 语法分析器的第一印象是“表填对了就能跑”。真正做过编译原理实验的人都知道卡人的不是敲不出那两三百行 Java而是表填完了、demo 跑通了换一个输入串立刻翻车报错还指在一个八竿子打不着的位置。SLR(1) 的核心是一套严格的构造顺序先有 LR(0) 项目集规范族再有 FOLLOW 集最后才轮得到 ACTION 和 GOTO 两张表。顺序错一步后面全靠试。这份 Java 实现的 SLR(1) 语法分析器把整条链路摊开摆在那里值得一层层拆开看。2. 项目集规范族LR(0) 自动机是算出来的不是画出来的教材上画自动机很轻松画几个圈标上I0、I1箭头一连就完事。真写代码时你会发现编译器并不知道该画几个圈它必须从一条增广产生式出发把所有可能的状态一个不漏地枚举出来还要保证同一个状态不会被重复创建两次。这一节讲的就是这个枚举过程怎么落地。2.1 产生式与项目怎么编码字符串进不了哈希表做算术文法一般从文本文件读入形如E - E T | T。读进来第一件事是拆成一条条产生式并在最前面补一条增广产生式S - E编号为 0。这个编号 0 不是随便定的后面判定 accept、以及闭包从哪个项目起步都靠它做锚点。拆完之后一个“项目”就不是E - E · T这种带点的字符串了而是一个二元组(产生式编号, 圆点位置)。用二元组的好处很实在能算哈希、能比较、能排序、能当 Map 的 key而字符串形态的项目在拼接和比较时又慢又容易因为空格不一致而对不上。归约动作也只需要存一个产生式编号真正要还原右部长度时再回表去查。// 一条产生式左部非终结符 右部符号数组编号即数组下标 static final class Production { final int id; final String lhs; final String[] rhs; // 长度可能为 0表示 ε 产生式 Production(int id, String lhs, String[] rhs) { this.id id; this.lhs lhs; this.rhs rhs; } int length() { return rhs.length; } } // 一个 LR(0) 项目圆点落在右部的哪个位置 static final class Item { final int prod; // 产生式编号 final int dot; // 0 dot rhs.length Item(int prod, int dot) { this.prod prod; this.dot dot; } // 圆点右边的符号dot 已到末尾时返回 null这是可归约的判据 String nextSymbol(ListProduction prods) { String[] rhs prods.get(prod).rhs; return dot rhs.length ? rhs[dot] : null; } Override public boolean equals(Object o) { if (!(o instanceof Item)) return false; Item x (Item) o; return prod x.prod dot x.dot; } Override public int hashCode() { return prod * 131 dot; } }nextSymbol是整份代码里被调用次数最多的方法它同时承担了三个判断返回值是终结符就产生移进是non终结符就触发闭包扩散是null就产生归约。把这三个分支收敛到一个方法里后面填表时的逻辑才不会散成一团。equals和hashCode必须手写而且必须只依赖prod和dot这两个字段。踩过一次坑早期版本把Item定义成可变对象圆点用原地推进结果塞进HashSet之后再修改哈希值变了contains永远返回 false闭包直接不收敛。项目对象天生适合做成不可变的。2.2 CLOSURE 的不动点为什么要用工作表反复扩散闭包的语义一句话能说完如果项目里圆点右边是个非终结符B那所有以B为左部的产生式都应该以“圆点在开头”的形式加进来。麻烦在于这是会传染的——新加进来的项目圆点右边可能又是一个非终结符得继续加直到再也加不进去为止。教材写法是“重复以下过程直到 I 不再增大”实现里如果真写成每轮全量扫描一遍集合复杂度会很难看。常规做法是用一个工作表worklist先把初始项目全部入队每次弹出一个看它需不需要扩散需要就把新项目入队同时用集合去重保证同一个项目只处理一次。// 求项目集闭包从 kernel 出发扩散到不动点 private SetItem closure(CollectionItem kernel) { DequeItem work new ArrayDeque(kernel); SetItem result new LinkedHashSet(kernel); while (!work.isEmpty()) { Item it work.poll(); String next it.nextSymbol(prods); // 圆点已到末尾或右边是终结符不会引入新项目 if (next null || isTerminal(next)) continue; for (int p : productionsOf(next)) { // 所有以 next 为左部的产生式编号 Item fresh new Item(p, 0); // 圆点固定在右部最左端 if (result.add(fresh)) { // add 返回 true 才说明是全新的 work.push(fresh); // 只有新增的项目才需要继续扩散 } } } return result; }这段代码能终止的根本原因是状态空间有限全部可能的项目总数等于“所有产生式右部长度加一之和”是个固定常数集合只增不减且每次增长都是往这个有限集合里塞一个没塞过的元素所以最多扩散这么多轮。result.add(fresh)的返回值是关键。很多人写成先if (!result.contains(fresh)) { result.add(fresh); work.push(fresh); }逻辑上没错但多了一次哈希查找。用LinkedHashSet而不是HashSet是为了让输出顺序稳定——调试打印项目集的时候如果每次顺序都不一样你根本没法用肉眼比对两次运行的结果差异。productionsOf建议在解析文法时就建成MapString, ListInteger不要在闭包里线性扫描整个产生式表。状态数上百、每个状态闭包要扩散几十次的时候这个索引的差别是肉眼可见的。2.3 GOTO 与状态去重key 不排序会造出一堆重复状态有了闭包GOTO(I, X)就简单了把I里所有圆点右边正好是X的项目挑出来圆点各自右移一格组成核kernel再对这个核求闭包。真正容易翻车的是“状态去重”这一步——你需要判断一个新算出来的项目集是不是已经存在过。判断相等不能靠Set.toString()。LinkedHashSet的toString依赖插入顺序而插入顺序又依赖你遍历I的顺序、闭包扩散的顺序两个内容完全相同、只是插入顺序不同的项目集拼出来的字符串就是两个不同的 key。表现出来就是状态数莫名其妙翻倍GOTO表里出现两行内容一模一样但编号不同的状态还可能一个状态报了移进-归约冲突、另一个没报。正确做法是先按(prod, dot)排序再拼 key// 把一个项目集压成稳定字符串先排序再拼接 private String keyOf(SetItem state) { ListItem sorted new ArrayList(state); sorted.sort(Comparator.comparingInt((Item x) - x.prod) .thenComparingInt(x - x.dot)); StringBuilder sb new StringBuilder(sorted.size() * 8); for (Item x : sorted) sb.append(x.prod).append(.).append(x.dot).append(;); return sb.toString(); }有了稳定 key规范族的构造就是一个典型的“边遍历边增长”的循环ListSetItem states new ArrayList(); MapString, Integer index new HashMap(); SetItem start closure(List.of(new Item(0, 0))); // S - ·S states.add(start); index.put(keyOf(start), 0); // 注意 i states.size()states 在循环体内会增长这是刻意为之 for (int i 0; i states.size(); i) { for (String sym : grammarSymbols) { // 固定顺序保证状态编号可复现 SetItem target goTo(states.get(i), sym); if (target.isEmpty()) continue; String k keyOf(target); Integer id index.get(k); if (id null) { id states.size(); states.add(target); index.put(k, id); } trans[i][symbolIndex(sym)] id; // 终结符列 移进目标非终结符列 GOTO } }循环条件写成i states.size()而不是提前把size()存成局部变量是这段代码的灵魂。新状态在循环体里被追加到尾部索引i往后走的时候自然会碰到它们整个算法就是一次广度优先遍历。如果把它写成int n states.size(); for (int i 0; i n; i)只会算出第一层状态GOTO表大片空缺然后你会以为是文法有问题。grammarSymbols用固定顺序比如先终结符后非终结符各自按首次出现顺序也很重要。状态编号是“首次被发现”的顺序顺序一变编号全变两张表就对不上了。调试时想复现上一次的状态编号就得靠这个固定顺序。如果文法规模大起来keyOf里的字符串拼接会成为瓶颈可以换成BitSet项目总数是个常量给每个项目分配一个全局下标一个状态就是一个BitSet相等比较和哈希都直接由BitSet提供还能顺带省内存。实验规模的文法十几个产生式用不着上这套但知道有这条升级路径读别人代码时就不会觉得那些BitSet用得多此一举。3. FOLLOW 集与归约决策SLR(1) 的那“一瞥”到底看什么LR(0) 自动机本身是“瞎”的它只知道圆点走到了产生式末尾该归约了却不关心下一个输入符号是什么。SLR(1) 补上的就是这一眼——归约时看一眼向前看符号只有这个符号落在左部非终结符的 FOLLOW 集里才允许归约。整个 SLR(1) 的表达力上限就压在这一条规则上。3.1 FIRST 与 FOLLOW 的不动点ε 是最容易漏的一环FIRST 集相对直白终结符的 FIRST 是它自己非终结符的 FIRST 要沿着产生式右部从左往右看遇到第一个不能推出 ε 的符号就停。FOLLOW 集则要绕一圈$天生属于开始符号对每条产生式A - α B βFIRST(β)里除 ε 外的符号都归B如果β能推出 ε那FOLLOW(A)也要归B。第二条规则是重灾区。很多人写 FOLLOW 的时候只处理了“β 的第一个符号是终结符”的情况β 为空或者 β 全是可空非终结符时就什么都不做结果某些非终结符的 FOLLOW 集缺了元素归约表里对应的格子是空的一个完全合法的句子在运行时被判语法错误。// 先算 nullable再算 FOLLOW这一步不能省 SetString nullable new HashSet(); boolean changed true; while (changed) { changed false; for (Production p : prods) { boolean allNull true; for (String s : p.rhs) { if (isTerminal(s) || !nullable.contains(s)) { allNull false; break; } } if (allNull nullable.add(p.lhs)) changed true; // 左部也变成可空 } } // FOLLOW 传播同样迭代到不动点 changed true; while (changed) { changed false; for (Production p : prods) { for (int i 0; i p.rhs.length; i) { String b p.rhs[i]; if (isTerminal(b)) continue; // 把 FIRST(β) - {ε} 并入 FOLLOW(b) int j i 1; while (j p.rhs.length) { changed | follow.get(b).addAll(firstOf(p.rhs[j], true)); if (!isNullable(p.rhs[j])) break; // 遇到不可空的符号就截断 j; } // β 整体可空或 β 为空把 FOLLOW(左部) 并入 FOLLOW(b) if (j p.rhs.length) changed | follow.get(b).addAll(follow.get(p.lhs)); } } }这段代码里firstOf(sym, includeEpsilon)用布尔参数区分“要不要把 ε 放进来”是必要的。FIRST 计算时需要 ε 来做终止判断FOLLOW 传播时又必须把 ε 剔掉混在一起写迟早出错。还有一个隐蔽的初始化陷阱follow这个 Map 必须在算 FOLLOW 之前给每个非终结符都put一个空HashSet。如果只在用到时computeIfAbsent某个从没出现在任何产生式右部的非终结符就永远没有条目而addAll(follow.get(x))在x不存在时会直接抛 NPE报错位置离真正的文法问题十万八千里。3.2 ACTION 表的填充冲突就是在某一格被写第二次时暴露的填表的规则只有三条但每条对应一种项目形态项目形态触发条件写入的动作A - α · a β圆点右边是终结符a在ACTION[state][a]写移进目标状态是GOTO(state, a)A - α ·A 不是 S圆点已到末尾对FOLLOW(A)里每个符号在ACTION[state][x]写归约携带产生式编号S - S ·增广产生式走到末尾在ACTION[state][$]写 accept注意第二条是按 FOLLOW 集“扇出”的一个可归约项目并不只对应一格它对应|FOLLOW(A)|格。这也解释了为什么文法里多一个非终结符、多一条可空产生式ACTION 表的非空格子会涨得很快。冲突检测就发生在写入的时候// type: 1移进, 2归约, 3acceptvalue: 目标状态 或 产生式编号 private void setAction(int state, String terminal, int type, int value, ListString conflicts) { int col termIndex(terminal); int old actionType[state][col]; if (old 0) { // 空格子直接写 actionType[state][col] type; actionValue[state][col] value; return; } if (old type actionValue[state][col] value) return; // 重复写入同一动作正常 // 已经非空且动作不同这就是冲突记录下来而不是覆盖 conflicts.add(String.format(状态 %d 遇符号 %s%s 与 %s 冲突, state, terminal, describe(old, actionValue[state][col]), describe(type, value))); }这里最常见的误操作是“后写的覆盖先写的”。一旦允许覆盖程序不会报任何错表也是满的只是行为变成任意的。文法本质上是二义的或者只是不满足 SLR(1) 条件但你看不到任何提示只能靠输入串出错的诡异表现反推。把冲突收集起来而不是吞掉是这份实现里最值得学的一个设计选择。3.3 冲突定位从一格冲突反推文法问题冲突信息里至少要带三样东西状态编号、终结符、双方的动作描述。缺一样都会让排查变成猜谜。只知道“文法有移进-归约冲突”毫无意义你手上有几十个状态。知道是状态 7、符号*、冲突双方是“移进到 12”和“按T - T * F归约”才有下手点把状态 7 的项目集打印出来一眼就能看到是哪个项目的圆点卡在*前面哪个项目已经走到末尾。常见的冲突成因有两个。一个是文法真有二义性比如经典的悬空 else 问题移进和归约都说得通得靠优先级规则来裁决而 SLR(1) 本身给不出答案。另一个是文法本身无二义但 FOLLOW 集给得太宽——这正是 SLR(1) 比不上 LALR(1) 的地方也是最后一章要展开的例子。排除顺序上先看是不是文法抄错了多一行少一行、|分隔漏了一层再看是不是 FOLLOW 算漏了最后才怀疑文法本来就不是 SLR(1)。实战里前两种占大多数。4. 表驱动执行循环一个 while 加四个分支如何吃掉任意输入串表和自动机都建好之后剩下的部分反而最短一个循环、一个栈、一个位置指针。短归短理解不到位照样写出死循环和错位报错。4.1 表结构选型实验规模用二维数组什么时候该换稀疏表ACTION 表是“状态数 × 终结符数”GOTO 表是“状态数 × 非终结符数”。表达式文法建出来大概十几个状态、七八个终结符二维int[][]撑死一百多格直接开数组最省事查表是纯下标运算不用装箱不用算哈希。用两个平行数组actionType和actionValue比用一个Action对象数组更实在。type用 0 表示错误格既是“空”也是“出错”省掉一次判空value在移进时存目标状态归约时存产生式编号语义由type决定不会混淆。什么时候该换MapLong, Action状态数上到几百、终结符几十个乘法一算就是几万格其中大多数是空的这时候数组浪费的内存会超过 Map 的哈希开销。稀疏表还有额外好处遍历非空格子做冲突统计更方便。实验作业不必上这套但你在读任何真实编译器前端的表实现时会看到大量“行压缩”“按列稀疏”的技巧本质上就是在处理同一个权衡。顺带一提value的正负号约定。有人喜欢用正数存移进、负数存归约、零存错误省掉 type 数组代价是 accept 和“归约到产生式 0”撞车还得专门留个魔数。用两个数组多四字节少一堆特判。4.2 双栈同步状态栈、符号栈、位置指针必须三方一致执行循环里维护三个东西状态栈存整数状态编号、符号栈存已经归约出来的语法树节点、输入位置指针。三者必须同步推进任何一方落后或超前报出来的错误位置都是错的。DequeInteger stateStack new ArrayDeque(); DequeNode nodeStack new ArrayDeque(); stateStack.push(0); // 初始状态 int pos 0; while (true) { int s stateStack.peek(); String look (pos tokens.size()) ? tokens.get(pos).text : $; int type actionType[s][termIndex(look)]; int value actionValue[s][termIndex(look)]; if (type 1) { // 移进 stateStack.push(value); nodeStack.push(leaf(tokens.get(pos))); // 位置指针只在这里前进 } else if (type 2) { // 归约 Production p prods.get(value); ListNode kids new ArrayList(p.length()); for (int k 0; k p.length(); k) { stateStack.pop(); kids.add(nodeStack.pop()); // 弹出顺序是反的后面要翻转 } Collections.reverse(kids); int top stateStack.peek(); int next gotoTable[top][nonTermIndex(p.lhs)]; if (next 0) throw new IllegalStateException(GOTO 表缺格 p.lhs); stateStack.push(next); nodeStack.push(new Node(p.lhs, kids)); // 归约出新的非终结符节点 } else if (type 3) { // accept return nodeStack.peek(); } else { throw new ParseException(pos, look, s); // 空表项 语法错误 } }三个细节值得单独说。第一pos只在移进分支自增。归约是“把已经读进来的东西重新组织”不消耗新输入。如果归约里也pos输入串会被吞掉一截报错位置整体偏移。第二归约弹栈次数是右部长度p.length()不是p.length() 1。状态栈里除了右部各符号对应的状态下面还压着一个“归约前”的状态那个不能弹归约完要用它去查 GOTO。第三归约完压入的是gotoTable[top][nonTermIndex(p.lhs)]用新的栈顶状态和左部非终结符查表。查出来是 0 说明 GOTO 表没填全通常意味着规范族构造被提前截断了回到 2.3 那个states.size()的坑这时候抛异常比让程序带着错表继续跑要好得多。4.3 语法树的构造时机归约时建节点子节点顺序要翻转树是在归约分支里建的不是在移进分支。原因很直接移进的时候你还不知道这个 token 最终属于哪个父节点圆点走完一个产生式父子关系才确定下来。kids的收集过程是“弹一个加一个”先弹出来的是最右边的子节点所以必须Collections.reverse。漏掉这一步的典型症状是树能建出来打印也没问题但做后续语义分析时发现二元表达式的左右操作数反了1 - 2算成2 - 1。这种错在小例子上看不出来等做四则运算求值时才炸。ε 产生式在这里有个特殊表现p.length() 0循环一次都不进状态栈不弹kids为空直接查gotoTable[top][p.lhs]并压栈。这本身是对的但要小心它带来的一个副作用——如果 GOTO 查出来的状态和当前栈顶状态一样而 ACTION 表里这个状态又允许同样的归约循环就会一直做同一件事永远不消耗输入。防这个的办法很土但有效给while加一个步数上限比如tokens.size() * 1000超了就抛“疑似死循环请检查 ε 产生式”。树节点的构造建议用不可变对象父节点引用在归约时一次性给定。想加回溯或者错误恢复的时候不可变树能省掉一大堆“改坏了原始树”的调试噩梦。5. 实现踩坑记录SLR(1) 分析器最容易翻车的五处下面这五条都是“程序在跑、没报异常、结果就是不对”的类型。它们的共同点是错误不在出问题的那一行而在更早的某个静默失败处。5.1 文法读入阶段的两个静默失败坑一非终结符没有产生式闭包静默跳过。现象输入串里出现一个文法中存在的符号程序却在某个位置报“语法错误”而且报错位置比真正的问题位置靠后很多。原因闭包方法里productionsOf(next)返回空列表for循环一次都不进不会报错也不会警告只是这个非终结符永远扩散不出任何项目。于是它在任何状态下都没有可移进的边遇到它必然落进 ACTION 的空格子。解决解析完文法后做一次完整性校验——收集所有出现在右部的非终结符逐个检查是否有对应产生式缺的立刻打印出来并终止。这是一行代码换半小时排查的买卖。坑二多字符终结符被拆成单字符。现象文法里写的是id输入x被判错或者输入id被识别成两个 token。原因分词阶段用charAt逐字符扫描id自然被拆成i和d或者反过来输入串按空格切分而文法里的终结符是单字符两边词法粒度不一致。解决词法先于语法且必须和文法用同一张终结符表。识别时按“最长匹配”原则先尝试长度最长的候选实在要做简化就在读文法时明确约定所有终结符都是单字符并在文档和代码注释里写死这个前提别让它变成隐性约定。5.2 表构造阶段的状态爆炸与冲突误判坑三状态 key 不排序同一个状态被建了两次。现象状态数比手工推导多出好几倍GOTO 表里有多行内容完全一样更诡异的是同一个文法两次运行冲突数量不一样。原因用Set.toString()当 key而LinkedHashSet的字符串形态依赖插入顺序闭包扩散顺序稍有变化就得到不同 key。解决按(prod, dot)排序后再拼 key或者用BitSet做全局项目下标的位图。排序这一步不能省它是状态去重正确性的前提不是优化。坑四FOLLOW 漏了“β 可空”分支归约表大片空缺。现象大部分输入能正常解析某些特定后缀的句子被拒错误位置恰好落在某个非终结符该出现的地方。原因A - α B β中 β 整体可空时要把FOLLOW(A)并入FOLLOW(B)。代码只处理了 β 以终结符开头的情况可空分支被跳过FOLLOW(B)缺元素B - ... ·的归约格没被填上。解决先独立算 nullable 集合再算 FOLLOW把“β 可空”写成显式分支别用if (i 1 rhs.length)这种看着省事其实漏一半的写法。5.3 运行阶段的死循环与错位报错坑五ε 产生式归约导致死循环。现象输入x之后程序卡住不动或者跑一会儿栈溢出日志里同一个状态同一个产生式刷了几千遍。原因归约A - ε时右部长度为 0状态栈不弹查 GOTO 得到的可能是当前同一个状态而该状态的 ACTION 在同一个向前看符号上仍然是这条归约于是无限循环。解决归约长度为 0 时只压栈不弹栈这是正确行为同时给主循环加步数上限超限时报出当前状态、当前符号和最近若干次动作让人一眼看出是在重复。加个上限远比事后对着卡死的进程抓栈要轻松。附带一条观察错误信息里必须带位置指针。只报“语法错误”而不报“第几个 token、这个 token 是什么、当前状态编号是多少”等于把排查成本全部转嫁给读日志的人。ParseException(pos, look, s)这三个参数是最低配置能带上一份期望符号集合更好。6. SLR(1) 的边界为什么它注定干不过 LALR(1)实验却还要做它要真正理解 SLR(1)得看一个它能建出冲突、而 LALR(1) 不会的例子。文法长这样S - L R | R L - * R | id R - L在 LR(0) 项目集里GOTO(I0, L)得到的那个状态包含两个项目S - L · R和R - L ·。前者要求看到就移进后者要求看到跟随符号就归约。SLR(1) 判断“跟随符号”的依据是整个文法里R的 FOLLOW 集而由于S - L R的存在确实在FOLLOW(R)里。两个动作撞在同一格移进-归约冲突SLR(1) 直接宣布这个文法不是 SLR(1) 文法。问题出在哪FOLLOW(R)是个全局量它把文法中所有位置对R的期待混在了一起。而在这一格所代表的具体上下文里R - L归约之后紧接着要跟的符号其实只可能是$——因为这条路径是从S - R过来的跟一点关系都没有。LALR(1) 的做法是给每个项目带上只在“这个状态下”有效的向前看集合把FOLLOW的全局信息收窄成局部信息冲突自然消失。6.1 用冲突计数当测试基准理解了这一点就有了一个不用肉眼比对状态图的验证手段准备三个文法。第一个是表达式文法公认的 SLR(1) 文法构造结果必须是 0 冲突状态数应该和手工推导一致十来个。第二个是上面那个L R文法必须精确报出 1 个移进-归约冲突且位置在GOTO(I0, L)对应的状态、符号是。第三个是带悬空 else 的文法必须报移进-归约冲突。三个都对上说明闭包、GOTO、FOLLOW、填表四段逻辑基本没错只要有一个数量对不上问题一定在表构造阶段而不在执行阶段范围立刻缩小。这个思路比“多试几个输入串看看对不对”靠谱得多因为输入串只能验证“接受的语言对不对”验证不了“这个文法被判定成了什么类型”。6.2 设计取舍为什么教学实验选 SLR(1)工业实现选 LALR(1)SLR(1) 的价值不在于它够强而在于它把 LR 分析的骨架完整暴露了出来且没有引入额外的复杂度。LALR(1) 要在 LR(0) 项目集上再叠一层向前看符号的传播算法状态数一样实现却要多出“传播”和“自发生成”两个概念规范 LR(1) 更直接状态数直接翻几倍表的大小立刻不可控。SLR(1) 处在那个刚刚好的位置概念完整、实现可控、失败可解释。真到了工程场景判断标准就反过来了。表的大小、构建时间、错误恢复能力每一样都比“实现简单”重要LALR(1) 是主流选择某些场景下干脆放弃表驱动改用递归下降手写分析器。而 SLR(1) 留给我们的遗产是那条构造链路——闭包、GOTO、规范族、FOLLOW、表填充、栈式驱动。这条链路在 LALR(1) 里一步都没少只是每步多了一点细节。我自己的习惯是拿到任何一份表驱动分析器的代码先不看执行循环直接去找“冲突是怎么被处理的”。如果冲突被静默覆盖这份代码的正确性就没法保证后面读多少都是在给一个不可靠的东西做注脚如果冲突被收集、被报告、甚至被分类那作者大概率是真的理解了自己在建什么。从那以后我每写一个分析器都强制先把“冲突计数”打出来看一遍0 也好、3 也好得先知道自己在什么位置上。这份 Java 实现里那套把冲突记录成可读字符串的做法值得当作模板留着。希望帮到你。本文还有配套的精品资源点击获取