语法分析实战：从LL(1)预测表到LR分析器的C++实现

简介：编译原理语法分析实验的C++代码与题面说明，面向需完成递归子程序法语法分析程序设计的学生，适合自学编译器实现的人士；资源包共2个文件，包括doc格式的问题描述和cpp格式的完整源码，压缩包仅17KB，内容精简。已有6109人学习，同类资源中热度较高；代码在CG实验平台满分通过，整体框架清晰，可放心参照。文档明确了实验要求：按文法规则用递归子程序法分析所有语法成分；源文件命名为testfile.txt，结果输出至output.txt，且需按词法分析顺序逐行输出单词，在指定语法成分分析结束前另起一行输出成分名，并注意预读情况不能输出。源码通过递归函数清晰展示了各类语法成分的识别顺序和词法分析结果的衔接，便于对照学习递归下降分析的实现。

1. 语法分析：为什么左递归会让程序跑到栈溢出、预测表空一格就让分析器翻车

语法分析器大概是编译原理实验里最像“玄学”的组件：代码写得再工整，只要文法里藏了一条左递归，程序就能直接消耗到栈溢出；预测表空掉一个格子，分析器又可能在第三个 token 上翻车。很多人把时间全部花在 C++ 的细节上，结果发现问题出在文法本身而不是代码。语法分析的底层只有一件事：把“如何从开始符号推导出这个句子”翻译成一组状态转移和一张表。C++ 语法分析实验正好把这条链路拆成了能单步跟踪的代码——读文法、算 FIRST/FOLLOW、构造预测表或 LR 分析表、再跑状态栈。把这一整套机制弄懂，自顶向下和自底向上两大体系就都打通了，之后遇到任何“解析炸了”的问题，你都能直接定位到文法或表项，而不是瞎改代码。

2. 自顶向下：LL(1) 的预测表、FIRST/FOLLOW 集与递归下降的 C++ 骨架

2.1 左递归为什么是死循环：先消除左递归，再写递归下降

递归下降（recursive descent）是最符合人类直觉的解析方式：每个非终结符对应一个 C++ 函数，函数的函数体就模拟这个非终结符的产生式右部。对于一个简单的表达式文法E -> E + T | T，直观写法是parseE()里第一件事就调用parseE()——这等于一个没有出口的递归，每次调用都重新进入自己，直到栈溢出。这并不是代码写得不好，而是文法结构本身就不适合这种实现方式。

出现“左递归死循环”的根源在于：递归下降函数天然假设“在继续推导之前，输入已经消费了一部分”，而左递归产生式A -> Aα却在消费任何输入之前，就要求先完成对 A 自身的推导。数学上，A -> Aα | β表示 A 可以展开成“一串 α 跟在 β 后面”，所以完全可以改写成右递归形式：

• 将A -> Aα | β改写为A -> β A'，A' -> α A' | ε。

用表达式文法做例子，消除左递归后变成：

E -> T E' E' -> + T E' | - T E' | ε T -> F T' T' -> * F T' | / F T' | ε F -> ( E ) | id

注意两个关键点：第一，E'和T'都多了一个ε分支，它代表“当前不需要继续展开，直接接受”；第二，右递归会产生一个不对称的推导树，E'不断向右生长，这正好匹配循环写法。工程上一个常见做法是直接用while循环代替递归的E'——后面写递归下降时我会给出这种等价替换。

提示：消除左递归是写递归下降前的第一道工序，不是可选项。忘掉这一步的代价不是“解析结果不对”，而是程序直接崩掉。

2.2 FIRST/FOLLOW 集合的固定点迭代：为什么集合会“越算越大”

LL(1) 的名字已经说明了它的工作前提：从左到右扫描输入（Left），推导出最左句型（Leftmost），向前看一个符号（1）。要做出一张能指导推导的预测表，必须先回答两个问题：某个非终结符“可能以哪些终结符开头”（FIRST），以及“某个非终结符后面可能跟着哪些终结符”（FOLLOW）。

FIRST 和 FOLLOW 都不是扫一遍文法就能得到的。以E' -> + T E' | ε为例，E'的 FIRST 包含+和ε；而E的 FIRST 依赖T的 FIRST，T的 FIRST 又依赖F的 FIRST，F的 FIRST 又依赖E——因为F -> ( E )。集合之间存在循环依赖，所以标准的求法是“固定点迭代”：不断把新元素并入集合，直到某一轮没有任何集合发生变化。

// EPS 是 ε 的专用符号编号，终结符编号从 1 开始，非终结符编号从 nt 之后开始 const int EPS = -1; std::set<int> first[MAX_SYMBOL]; // 每个符号的 FIRST 集合 void computeFirst(const Grammar& g) { bool changed = true; while (changed) { changed = false; for (const Production& p : g.prods) { // 逐一检查每条产生式 int A = p.lhs; bool canBeEmpty = true; // 右部是否可推导出 ε for (int s : p.rhs) { if (g.isTerminal(s)) { // 终结符直接收入 FIRST if (first[A].insert(s).second) changed = true; canBeEmpty = false; break; } for (int e : first[s]) // 非终结符：并入它的 FIRST if (e != EPS && first[A].insert(e).second) changed = true; if (!first[s].count(EPS)) { // 右部遇到不可空的符号 canBeEmpty = false; break; } } if (canBeEmpty) // 整个右部都可为空 if (first[A].insert(EPS).second) changed = true; } } }

这段代码里最值得琢磨的是“只增不减”的性质：std::set的insert天然保证去重，所以每轮循环要么插入新元素，要么什么都不发生；而符号总数是有限的，循环必然终止。这也是固定点算法的经典特征——它在数学上保证收敛，只是不保证收敛速度快。实际写实验时，很多人偷懒只扫一遍文法，结果E -> F这种传递关系根本没传完，预测表就会缺行缺列。正确做法就是像上面这样用while (changed)包住全部产生式扫描，直到稳定。FOLLOW 的求法同理：对A -> αBβ，把FIRST(β)中非 ε 的元素并入FOLLOW(B)；如果 β 可为空，再把FOLLOW(A)整体并入FOLLOW(B)。注意 FOLLOW 依赖 FIRST，所以最省事的做法是“先算完 FIRST，再按同样的固定点方式算 FOLLOW”。

2.3 预测表构建与递归下降子程序：同一个表，两种执行方式

有了 FIRST 和 FOLLOW，LL(1) 预测表就只剩一行规则：对产生式A -> α，把a ∈ FIRST(α)的每个终结符a填入表项M[A][a]；如果α可推导出 ε，则把FOLLOW(A)中的每个终结符也填入。同一个格子被填入两条不同产生式，就说明文法不是 LL(1)，要么提取公共左因子，要么换 LR 方案。C++ 实现里，表可以是一个二维数组，每个单元存一个产生式编号，0 表示“错误”。

// table[A][a] = 产生式编号或 0（错误）；add 时检测冲突 void buildLL1Table(const Grammar& g) { for (const Production& p : g.prods) { std::set<int> ft = firstSeq(p, g); // FIRST(p.rhs) for (int a : ft) if (a != EPS && !add(table[p.lhs][a], p.id)) reportConflict(p); // 同一格出现两条候选 if (ft.count(EPS)) // 右部可空 for (int a : g.follow[p.lhs]) if (!add(table[p.lhs][a], p.id)) reportConflict(p); } }

firstSeq的实现和上面的computeFirst是同一个套路：逐个遍历右部符号，遇到终结符直接加入并停止；遇到非终结符则并入其 FIRST，只有当前符号可为空时才继续向右看。注意ε本身不会出现在预测表的格子里，它只作为“右部可为空”的标志，决定是否启用 FOLLOW 兜底规则。

有了这张表，就有两种执行方式。表驱动版的 LL(1) 分析器用一个符号栈，反复查表决定“替换栈顶非终结符”还是“匹配终结符”；而递归下降版把表的逻辑揉进了函数调用结构里，E'的ε分支表现得特别明显：

// 递归下降：E' -> + T E' | - T E' | ε // lookahead 是当前扫描到的 Token，match() 成功则消费 token bool parseEPrime() { if (lookahead.type == T_PLUS || lookahead.type == T_MINUS) { match(lookahead.type); // 消费 + 或 - return parseT() && parseEPrime(); // 继续处理剩余 E' } // ε 分支：lookahead 属于 FOLLOW(E')，直接接受 return lookahead.type == T_RPAREN || lookahead.type == T_END; }

看到没有，代码里根本没有“表”，但parseEPrime最后的那个return条件，其实就是查FOLLOW(E')这张隐形的表。很多实验里有人把ε分支写成“什么也不做直接返回 true”，看起来也对，但遇到错误输入时会少掉一个检查点。递归下降的每个if分支都对应预测表的一列，这就是表驱动与函数调用在机制上的同构。此时再回头看 2.1 的“先消左递归再写递归下降”，你会发现右递归产生的E'在代码里天然就是一个“循环或尾递归”，而左递归文法在代码层面没有任何对应的合法形态——这不是风格问题，是文法结构决定的。

3. 自底向上：LR 分析表如何把“决策”变成“状态转移”

3.1 从移进-归约到 LR(0) 项目自动机：句柄识别为什么需要闭包

自底向上的思路是反着来的：读入 token 时先全部压进分析栈（shift），一旦发现栈顶的符号序列构成某个产生式的右部，就把它们弹出来、换成左部非终结符（reduce）。这个过程里最关键的问题是：怎么知道“现在该 shift 还是 reduce”，又该 reduce 哪一条产生式？答案是构造一个有限状态自动机，用状态来记录“当前推导进行到了哪一步”。这个自动机的一个状态是一组“项目”，而“项目”就是带点的产生式，例如E -> E + . T：点左边的符号已经入栈，点右边的符号还等待着。

从初始项目S' -> . E出发，需要用 CLOSURE 运算把“点后面是非终结符”的所有候选产生式加进来：如果项目集中有[A -> α . B β]，而B -> γ是文法中的产生式，那么[B -> . γ]也必须在这个项目集里。这背后的语义是：既然 B 马上要被推导，那么所有以 B 开头的右部都是当前合法的“未来”。C++ 里可以用std::set<Item>表示项目集，用 worklist 实现闭包：

struct Item { int prodId; // 产生式编号 int dotPos; // 点的位置，0 表示点在开头 bool operator<(const Item& o) const { if (prodId != o.prodId) return prodId < o.prodId; return dotPos < o.dotPos; } }; ItemSet closure(const ItemSet& init, const Grammar& g) { ItemSet result = init; std::vector<Item> worklist(init.begin(), init.end()); while (!worklist.empty()) { Item item = worklist.back(); worklist.pop_back(); // 点已经在末尾，没有待推导的符号 if (item.dotPos >= g.prods[item.prodId].rhs.size()) continue; int sym = g.prods[item.prodId].rhs[item.dotPos]; if (!g.isNonTerminal(sym)) continue; // 点后是终结符，无需展开 for (const Production& p : g.prodsByLhs[sym]) { Item nxt{p.id, 0}; // B -> . γ if (result.insert(nxt).second) worklist.push_back(nxt); // 新项目也可能触发新的闭包 } } return result; }

注意这里为什么用 worklist 而不是简单 for 循环：闭包展开是传递性的，[B -> . γ]加入后，如果 γ 的第一个符号又是非终结符，它还会引出新的候选项目。用集合去重配合待处理列表，能保证每个项目最多被展开一次，这也让算法在set的operator<支持下保持确定性。

有了 CLOSURE，GOTO 运算就顺理成章：从项目集 I 出发，把所有点后恰好是符号 X 的项目“点向后移一位”，再对结果做一次 CLOSURE。一个项目集加上若干 GOTO 边，就构成了 LR 自动机。在这个自动机上，每个状态都对应分析器的一个“已读入的东西都合法”的快照。

3.2 SLR 的 ACTION/GOTO 表：reduce 时机为什么只看 FOLLOW

LR 自动机本身只记录了“推导进度”，真正指导动作的是从自动机导出的 ACTION 表和 GOTO 表。ACTION 表的行是状态编号，列是终结符，表项写着一个动作：shift（把符号移进栈）、reduce（按某条产生式归约）、accept（接受）或 error。GOTO 表则负责处理归约后才能确定的非终结符转移。

SLR（Simple LR）是教学中最先接触的表构造法，它的归约条件只有一条：如果项目集中有A -> α .（点在末尾，表示 α 已经完整出现在栈顶），就用A -> α归约，但前提是当前 lookahead 属于FOLLOW(A)。这个规则看起来很简单，但它有个致命弱点：FOLLOW 集合是“全局统计”而非“上下文精确”的。一个非终结符 A 出现在文法多个位置，FOLLOW(A) 是把所有可能后继求并集；当两个归约项目的 FOLLOW 集合重叠时，SLR 会在同一个格子产生 reduce-reduce 冲突。

经典例子是这样一个文法：S -> a A d | a B e | b A e | b B d，A -> c，B -> c。当分析器读入 c 之后、即将归约时，SLR 查到的 FOLLOW(A) 和 FOLLOW(B) 都是{d, e}，于是表项M[state][d]上同时有 reduce A 和 reduce B。实际上输入串a c d必须归约 A，a c e必须归约 B——这个信息 SLR 完全看不到，因为它只看 FOLLOW，不看“这个产生式是从哪条路径被期望的”。

SLR 的构造复杂度低，状态数少，适合手工实验。但它的能力上限就是“没有这类上下文冲突的文法”。要突破这个上限，必须把向前看信息从“全局的 FOLLOW”细化到“每一条具体路径未来的第一个符号”，这就引出 LR(1)。

3.3 LR(1) 与 LALR：向前看符号是如何解决 SLR 冲突的

LR(1) 的项目从[A -> α . β]变成[A -> α . β, a]，其中 a 是这个项目被启用时“实际期望的向前看终结符”。它改变了闭包运算的传播规则：对[A -> α . B β, a]，给 B 的每个候选产生式B -> γ加入项目[B -> . γ, b]，其中 b 必须属于FIRST(β a)——也就是“B 后面紧接着的那个位置可能出现的终结符”。

拿上面那个冲突文法举例，当自动机进入包含归约项目的状态时，项目会带上各自的向前看：[A -> c ., d]和[B -> c ., e]。于是查表时，lookahead 是 d 就归约 A，是 e 就归约 B，冲突消失。这就是 LR(1) 的精确性来源：它把 FOLLOW 的并集拆散到每个项目、每条路径上，代价是状态数暴涨——同样的文法，LR(1) 自动机的状态数可能是 LR(0) 状态的数倍。

实际工程里很少直接构造完整 LR(1) 表，因为表大到不可维护。LALR(1)（Look-Ahead LR）的聪明之处在于：先构造 LR(0) 状态，再把那些“项目相同、仅向前看集合不同”的同心状态合并回去。合并后状态数与 LR(0) 相同，表规模回到 SLR 的水平，但归约时使用的是合并后的向前看集合。多数情况下合并不会引入新冲突，但如果合并后同一个归约动作的 lookahead 集合出现重叠，就说明该文法连 LALR(1) 也伺候不了。常见解析器生成器正是基于 LALR(1)——这是课堂实验与真实编译器之间的关键桥梁。

这张表值得反复看：状态数少不代表能力差，LALR 用“几乎不增状态”换来了远超 SLR 的表达能力，这才是它的工程价值。

4. 核心实现：C++ 对象模型与状态栈驱动的运行细节

4.1 符号编号与文法表示：从“人看的符号”到“机器看的整数”

语法分析代码里最常见的隐患不是算法难，而是“人写的公式符号”和“程序里的整数编号”对应不上。C++ 实现里，终结符通常直接复用词法分析的 TokenType 枚举，输入结束符用一个单独编号，ε 再用一个不可能与真实符号冲突的负数编号：

const int SENTINEL = 0; // 输入结束符 '#' const int EPS = -1; // ε 专用占位符 // 终结符编号从 1 开始 enum TokenType : int { T_PLUS = 1, T_STAR = 2, T_LPAREN = 3, T_RPAREN = 4, T_ID = 5 }; struct Production { int lhs; // 左部非终结符编号 std::vector<int> rhs; // 右部符号序列，EPS 表示空产生式 };

把 EPS 和 SENTINEL 分开编号是一个看起来不起眼、实际非常关键的约定。如果把 ε 编成 0，那它和输入结束符共用编号，分析栈在“遇到 0 时到底该匹配还是该跳过”上会行为错乱。使用-1后，FIRST 集合里的 EPS 只承担“可空”标记，永远不进入匹配循环；而 SENTINEL 作为真正的输入末尾，只出现在 FOLLOW 集合里。这段设计的本质是把“文法的元符号”和“输入串的符号”放进两个互不干扰的编号空间。

文法类还会预计算prodsByLhs（按左部索引的产生式列表），因为 CLOSURE 运算需要从“某个非终结符 B”快速拿到“所有 B 的产生式”。这个索引是 LR 自动机构造的性能关键——如果没有它，每个闭包步骤都要线性扫描全部产生式，文法一变大，构造时间就指数恶化。

4.2 栈驱动循环：shift、reduce、accept 的完整状态机

LL(1) 表驱动的核心循环比递归下降更容易观察“栈”与“表”的关系。分析栈存放文法符号，栈底是#，栈顶是要处理的符号：

// 栈顶为终结符则直接与输入匹配；为非终结符则查表展开 while (true) { int top = stk.back(); if (isTerminal(top)) { if (top == lookahead.type) { stk.pop_back(); lookahead = scanner.next(); // 消费输入 } else { recoverAndReport(); // 匹配失败，进入错误恢复 } } else { int rule = table[top][lookahead.type]; // 查 LL(1) 预测表 if (rule == 0) { recoverAndReport(); continue; } stk.pop_back(); const auto& rhs = prods[rule].rhs; for (auto it = rhs.rbegin(); it != rhs.rend(); ++it) if (*it != EPS) stk.push_back(*it); // 倒序压栈，保持推导顺序 } }

这段代码值得注意的细节是倒序压栈：栈顶是“下一个要被处理的符号”，所以推入右部时必须从最后一个符号开始，依次压到栈顶，才能保证第一个符号最先被弹出。EPS在这里被显式跳过——它不占据栈的位置，因为 ε 已经隐含在“产生式右部为空”这个判断里了。这个循环每轮只做三件事之一：匹配终结符、展开非终结符、报错。整个推导过程被压扁成一台确定性的下推自动机，这比递归下降的“函数调用栈”更接近编译原理里自动机理论的原貌。

LR 分析的驱动循环则是另一番景象：它维护两个平行的栈，一个存状态编号，一个存文法符号。shift 时两个栈都压入新内容，reduce 时两个栈同时弹出右部长度个元素，再查 GOTO 表压入新状态：

// action[s][a] 保存动作；gotoTable[s][A] 保存归约后的转移状态 while (true) { int s = stateStk.back(); int a = lookahead.type; if (action[s][a].kind == SHIFT) { stateStk.push_back(action[s][a].val); // 新状态入栈 symStk.push_back(a); // 符号入栈 lookahead = scanner.next(); } else if (action[s][a].kind == REDUCE) { const Production& prod = prods[action[s][a].val]; for (size_t i = 0; i < prod.rhs.size(); ++i) { symStk.pop_back(); // 弹出右部符号 stateStk.pop_back(); // 同步弹出状态 } int prevState = stateStk.back(); // 归约后应看哪个状态 symStk.push_back(prod.lhs); stateStk.push_back(gotoTable[prevState][prod.lhs]); // 转入新状态 } else if (action[s][a].kind == ACCEPT) { break; // 分析成功 } else { recoverFromError(); } }

LR 的 reduce 操作在机制上相当于“撤销右部符号的入栈动作，然后按文法结构重新组织”。弹出右部长度个状态、再压入一个 GOTO 状态，这一步正是“句柄归约”在栈上的投影：右部符号被“折叠”为左部非终结符，而 GOTO 保证了新的栈顶状态记得这个非终结符是在什么上下文中被推导出来的。理解了这个弹压过程，这个概念模型才能和代码对上，因为 LR 的“状态”并不是符号本身，而是「符号序列的合法推导进度」。

4.3 错误恢复：panic mode 与同步符号的选择

分析器遇到非法输入时，完整语法分析器不能直接抛异常退出——它要尽量多报几个错，至少要报告一个“错误位置”后还能继续。实验中常见的实现思路是 panic mode（恐慌模式）：丢弃输入中的 Token，直到遇到一个“同步符号”；同时把分析栈弹出一些符号，使后续输入能够重新匹配。

同步符号的选择有讲究。LL(1) 分析中，常用的同步符号是语句结束符（如;）、右括号和输入结束符。这些符号在句法结构中有明确的“分隔”作用——遇到它们，说明一个完整的语法单元刚结束，可以重新进入稳定状态。在预测表驱动循环里，当查表失败时，一种稳妥做法是：不断弹出栈顶符号，直到栈顶符号的 FOLLOW 集合包含当前 lookahead，此时恢复匹配；如果 lookahead 本身就在同步集合里，也可以直接丢弃它继续。

LR 分析器的错误恢复更复杂：因为状态栈记录了详细的推导上下文，简单弹栈很容易把状态栈搞成“不合法状态”。真正的 LR 错误恢复还需要同时修改状态栈，找到“允许接受当前 lookahead 的最近状态”，比 LL 的“弹到同步符号”多一层动作。课程实验里通常只要求实现最基本的版本：报告错误、丢弃输入到同步符号、重新尝试。这里想强调的一点是：错误恢复策略的选择直接影响解析器的“容错性格”——同步符号选得保守，报错就密集但定位准；选得激进，错误传播范围大，后续报错全是“假错”。这部分不值得过度设计，但值得把“为什么错误恢复这么难”想清楚：语法分析的本质是状态转移，任何恢复本质上都是“从非法状态想办法回到合法状态”。

5. 语法分析实验避坑：五个最容易翻车的位置

5.1 FIRST/FOLLOW 只扫一遍就收工，表里永远缺项

现象：预测表建出来之后，空白格比预期多很多；拿一个合法句子运行，分析器在很靠前的位置就报错，而且报错位置非常不符合直觉。

原因：FIRST 和 FOLLOW 存在循环依赖（典型如E -> F、F -> ( E )），集合必须迭代到不动点。只扫一遍文法，很多传递关系还没传播完，集合就已经“看起来算完了”；实际上那些通过两步以上推导才能到达的终结符全都丢了。

解决：把整轮计算放进while (changed)循环，所有集合共享同一个changed标志；每轮从头到尾重扫所有产生式，直到标志不再变化。实验里可以先打印每个非终结符的 FIRST/FOLLOW 结果，和手工计算结果逐项核对，再进表构造环节。

5.2 ε 和输入结束符共用编号，分析栈行为变得不可预期

现象：表驱动分析器偶发地把 ε 当作输入符号处理，或者在匹配#时莫名弹出；递归下降版本里ε分支“有时能过、有时不能过”。

原因：代码里把 EPS 定义成 0，而 0 又是 SENTINEL（输入结束符）的编号。FIRST 集合里的 EPS 和 FOLLOW 里的 SENTINEL 混在一起，表项构建时无法区分“右部可空”和“输入已结束”，导致同一格填进了错误的产生式。

解决：把 EPS 定义为负数（-1），作为纯内部占位符，永不出现在 Token 流里。更彻底的做法是在文法接口层就把 EPS 排除掉——FIRST 集合里的 EPS 只在“判断可空”时读取，不再参与任何表项填充。

5.3 直接对左递归文法写递归下降，代码一运行就栈溢出

现象：函数自我调用层数不断增长，程序卡死或直接 Segmentation Fault；加打印后发现parseE被无限重复调用，lookahead 始终没动。

原因：没有在动手前做“消除左递归 + 提取公共左因子”这两件事。左递归产生式在递归下降中对应“未消费输入就自我调用”，这在机器上是无终止递归。

解决：每个人在处理有递归的文法时，都应当先写一遍“文法化简”这一步：左递归转右递归、提取公共左因子，然后再对照化简后的产生式写函数。值得注意的一点是提取左因子后的文法可能仍然不是 LL(1)，此时就要果断切换到 LR 路线，不要死磕递归下降。

5.4 预测表构造时不检测冲突，二义性文法被执行成“随机行为”

现象：某些输入串能解析成功，某些相同的输入串换个顺序却解析失败；甚至同一个串在同一次运行里结果都不稳定。

原因：二义性文法（或非 LL(1) 文法）会导致同一表项M[A][a]出现两个候选产生式。若代码只是简单覆盖写入，后写的产生式会“赢”，而这个覆盖顺序取决于产生式存储顺序，看起来就像随机行为。

解决：add函数返回 bool，检测到目标格非零时立刻输出冲突的双方产生式并停止构建。这一步能把“运行时诡异”提前成“构建时报错”，大大节省排查时间。二义性文法的处理应该是有意识的取舍——比如把if-else悬空 else 的优先级显式写进文法，而不是靠表覆盖碰运气。

5.5 词法接口与文法符号编号错位，表查不到但报错位置匪夷所思

现象：分析器报错说在id位置期望某个终结符，但文法里F -> ( E ) | id明明允许 id；打印 Token 流发现类型枚举和文法编号根本不是一套。

原因：词法分析器返回的 TokenType 枚举（例如 5 = T_ID）和语法分析器文法符号编号（例如id编成了 42）来自两套常量定义，中间缺少映射。语法分析器查表时用 TokenType 去索引列，自然查不到任何有效项。

解决：单一数据源原则——词法分析器对外暴露的 TokenType 枚举本身就是文法终结符编号，文法文件里出现的所有终结符必须通过同一份symbol.h映射。如果实验用了自动生成工具，更要在生成后检查编号一致性。这个坑在学校里几乎没有出现过，因为自己写的代码只有一套常量；一旦换成 C++ 工程把词法、语法拆成多个模块，它就变成最常见的联调事故排查切入点了。

6. 递归下降还是 LR：从手写要控制，生成要完备的设计取舍

手写递归下降的最大优势不是“简单”，而是可控。解析器的错误消息、同步逻辑、回溯策略都可以按语句级需求定制；表达式里用运算符优先级实现，语句级用递归下降，这在真实语言解析器里非常常见。代价是表达式文法稍复杂就难满足 LL(1)，而且“手写”意味着代码结构和文法演进绑定，改语法就得改代码。

LR/LALR 类表驱动的最大优势是完备：只要文法通过冲突检测，分析器对任何合法输入的接受与拒绝行为都是自动化的，开发者不用关心“这个结构能不能匹配”，只需构造文法。代价是表不透明，运行期错误恢复难做。

在课程实验的语境里，这两条路线各有适合的选题：递归下降适合验证“自己实现一个能跑的解析器”；LR 适合验证“理解自动机如何指导分析”。如果你想自己验证实现是否正确，有一种比较省事的做法：把预测表和分析栈完整打印出来，输入一个简单串，手工推演几步看代码是否一致；再故意喂错误输入，看错误恢复后的下一个报错位置是否合理。这类验证比对着输出结果猜测更有诊断价值。

我自己在这个实验里最深的一课，是有一半以上的时间花在“栈、表、编号”这些和语言理论无关的细节上。只要有一处符号编号错位、一套集合少迭代一轮、一条产生式没消左递归，整台分析器就会给出看似合理实则错乱的输出，而且这种错乱比直接崩溃更难以察觉。从那以后，我拿到任何语法分析代码，第一步永远是打印 FIRST/FOLLOW 和完整分析表，手工核对一列再去跑样例；改文法时强制自己先走一遍“消除左递归 → 检查冲突 → 单步验证”的流程。这个顺序能帮你筛掉绝大多数“跑不起来”和“跑了但不对”的坑，也让真正的原理——状态转移、集合不动点、句柄归约——不再藏在代码背后。希望帮到你。

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