简介：基于C++实现根据文法自动生成LL(1)文法分析器，是一份面向编译原理课程设计的中小型工程源码，适合需要动手实现预测分析器、理解FIRST/FOLLOW集构造与预测分析表生成的读者。压缩包共11个文件，以8个C++源文件为主，另含1个头文件、1份Markdown说明文档和1份许可证文件，整体仅12KB。C++代码按功能模块拆分，覆盖文法预处理、FIRST/FOLLOW集合计算、冲突检测、分析表生成、核心分析流程及调试输出等环节，结构清晰，便于对照学习。当前已有406人浏览下载。通过该资源，读者可以获得一个可运行的LL(1)分析器参考实现，不仅能直接用于课程设计验收，还能借助自带文档理解文法解析、集合运算和错误处理的完整思路；同时基于STL容器和面向对象封装，也方便在此基础上扩展或改写。整体来说，这个小型项目将编译原理理论落到实际C++代码中，对巩固LL(1)分析原理和提升代码实践能力都很有帮助。

1. 这可能是你离“编译器前端”最近的一次：C++ 实现的 LL(1) 分析器怎么用

如果编译原理课设里有一个必须拿下的环节，那大概率是 LL(1) 文法分析器：给一套文法，算 FIRST、FOLLOW，建预测表，再拿它去分析一串输入。这套 C++ 实现的价值在于，它不是只演示一个固定文法，而是输入任何文法规则都能自动完成“预处理 → 集合计算 → 冲突检测 → 预测表生成 → 表驱动分析”整条链路。对正在做课程设计的人，这是可以直接抄作业的完整工程；对想搞懂编译前端原理的人，它把每个环节拆成了独立的 .cpp 文件，跟着走一遍就明白黑匣子里发生什么。项目文件里能看到 preprocess、get_first、get_follow、generator、analyze 这些拆分清楚的模块，编译后跑一个文法文件，终端里就能看到最终预测分析表和冲突标记。

2. 把文法变成程序能处理的数据：预处理流程与核心数据结构设计

LL(1) 分析器能不能跑通，第一道坎不在算法，而在“文法”怎么进入程序。从资源包的文件排布能看到，项目把整条管线拆成了 preprocess.cpp、get_first.cpp、get_follow.cpp、generator.cpp、analyze.cpp 五个步骤文件，加上一个 common_header.h 和 global.cpp 来共享数据类型。这个分工很典型，也是一般我这几年看课设代码觉得“最顺眼”的写法——每一步只做一件事，集合出错了直接定位到对应文件。

2.1 消除左递归与提取左因子：预处理到底跑哪几步

严格来说，LL(1) 文法本身不允许左递归，也不允许同一非终结符的多个候选首符号相同。但直接给用户一个“只能接受标准 LL(1) 文法”的工具，使用体验很差。所以常见的做法是：预处理阶段先做两件事——消除直接左递归和提取左因子。如果文法太大或出现间接左递归，程序也可以选择直接提示“无法自动处理”，把判断权还给用户。这份资源里的 preprocess.cpp 我推测做的就是这件事，同时把终结符、非终结符统一编号。

// preprocess.cpp 中的核心处理骨架（简化） // 输入: 形如 "E -> E + T | T" 的文法行 // 输出: 消除左递归后的产生式列表，写入全局容器 g_productions bool PreprocessGrammar() { for (auto& line : rawLines) { string nonTerminal = GetLeftPart(line); // 箭头左侧 vector<string> candidates = SplitByOr(line); // 按 | 拆候选式 vector<string> directLeft, other; for (auto& cand : candidates) { if (cand.size() >= nonTerminal.size() && cand.rfind(nonTerminal, 0) == 0) { // 候选式以自身开头 directLeft.push_back(cand); } else { other.push_back(cand); } } if (!directLeft.empty()) { EliminateDirectLeftRecursion(nonTerminal, other, directLeft); } else { g_productions[nonTerminal] = other; } } return true; }

这段逻辑里最关键的分支就是rfind(nonTerminal, 0) == 0，它判断“产生式右部是否以同一个非终结符开头”。如果是，说明存在直接左递归A -> Aα | β，需要引入一个辅助非终结符 A'，改写为A -> βA'、A' -> αA' | ε。参数上要注意：只有开头的非终结符相同才算左递归，E -> T + E这种左部符号出现在右部但不在首位，不是左递归，不需要动。预处理完成后，所有产生式会平铺到全局容器里，后续三个算法文件都只认这套编号结构，不再关心原始字符串长什么样。

2.2 产生式与符号表：为什么建议用编号代替字符串

用字符串直接做 FIRST/FOLLOW 集合运算不是不行，但字符串的==比较、set存储、输出对齐都很拖慢速度，调试时还会被空格和换行干扰。这个项目采用的是偏底层的方案：common_header.h里定义符号编号，std::string 只在读取文法那一刻出现，之后全用 int。每个非终结符、终结符对应一个唯一编号，空串 ε 用一个特殊编号预留。这样集合运算只要对 int 做操作，打印时再反向查表换回名字。

// common_header.h 中的核心声明（简化） using Symbol = int; // 所有终结符/非终结符统一用 int 编号 const Symbol EPSILON = -1; // 给 ε 分配的固定编号，特殊标记 struct Production { Symbol left; // 产生式左部非终结符 vector<Symbol> right; // 右部符号序列，EPSILON 表示空串 }; extern map<Symbol, string> g_symbol2name; // 编号 -> 原始名称，打印时用 extern map<string, Symbol> g_name2symbol; // 名称 -> 编号，建表时用 extern vector<Production> g_productions; // 预处理后的产生式全集 extern Symbol g_startSymbol; // 增广文法开始符号 S' extern map<Symbol, vector<Symbol>> g_first; // FIRST 集合 extern map<Symbol, vector<Symbol>> g_follow; // FOLLOW 集合

参数说明里最值得留意的是EPSILON = -1：正常符号编号从 0 开始，ε 单独占用负编号，这样firstSet.find(EPSILON) != firstSet.end()就能判断“该非终结符能否推导出空串”，不需要再维护一套 nullable 标记。g_productions用 vector 平铺而不是嵌套 map，是因为后续 FOLLOW 集计算要反复扫描全部产生式，平铺结构遍历最快。g_symbol2name和g_name2symbol是两个方向的映射表，读文法时填正向，打印时反向查，这种双表设计在课设答辩时也很加分，能直接回答“你怎么处理符号名”。

2.3 全局变量与模块划分：这个项目是怎么组织的

resources 里的文件排序是 common_header.h、global.cpp、preprocess.cpp、get_first.cpp、get_follow.cpp、generator.cpp、analyze.cpp、main.cpp、test_print.cpp。实际跑起来，main.cpp 只做顺序调度：读文件 → 预处理 → 算 FIRST → 算 FOLLOW → 生成预测表 → 分析输入串。global.cpp 负责初始化那几张映射表和产生式容器，是在一切正式开始前执行的。

test_print.cpp 是一个容易被忽视但很实用的模块。它不参与算法，专门打印中间状态：符号编号表、每条产生式、FIRST 集合内容、FOLLOW 集合内容。课设调试阶段最怕的就是“集合算错了，但不知道在哪里错的”，有这个打印模块，每一步的结果都能肉眼检查。我一般会在 main.cpp 里加一个debug参数，为 1 时调用 test_print 输出全部中间量，为 0 时只输出最终结果，这个习惯对排错帮助极大。文件职责如下表所示：

3. FIRST 集与 FOLLOW 集：C++ 实现集合闭包计算的两种写法

集合计算是整个分析器的算法核心。FIRST 集描述“一个非终结符能开头的所有终结符”，FOLLOW 集描述“一个非终结符后面可能跟着哪些终结符”。这两张表算错，后面的预测表一定错。get_first.cpp 和 get_follow.cpp 的算法思路差不多，都是反复扫描产生式直到集合不再增长，但实现细节差异很大，分开看。

3.1 FIRST 集递归计算：一张结果表、一张访问状态表

FIRST 集可以递归定义，对产生式A -> X1 X2 ... Xn，依次看每个 Xi：如果 Xi 是终结符，把它加进 FIRST(A) 后立即结束；如果 Xi 是非终结符，把 FIRST(Xi) 中除 ε 以外的符号全加进 FIRST(A)，只有当 FIRST(Xi) 含 ε 时才继续看 Xi+1。递归函数最怕死循环，比如文法里出现A -> B、B -> A或更隐蔽的环路。常见做法是加一张visiting标记表，符号正在递归计算中时再次遇到，直接返回，不再往下钻。

// get_first.cpp 中的递归计算（简化） set<Symbol> firstSet; map<Symbol, bool> calculated; // 是否已经算出结果 map<Symbol, bool> visiting; // 是否在递归栈上，防环 set<Symbol> GetFirst(Symbol X) { if (calculated[X]) return firstSets[X]; // 已算过，直接返回缓存结果 if (visiting[X]) return {}; // 正在算，说明有环，先返回空 visiting[X] = true; set<Symbol> result; if (!IsNonTerminal(X)) { // 终结符或 ε result.insert(X); } else { for (auto& prod : g_productions) { if (prod.left != X) continue; bool canDeriveEmpty = true; for (Symbol sym : prod.right) { set<Symbol> sub = GetFirst(sym); for (Symbol s : sub) { if (s != EPSILON) result.insert(s); } if (sub.find(EPSILON) == sub.end()) { canDeriveEmpty = false; break; // 遇到不能推导出 ε 的符号，停止 } } if (canDeriveEmpty) result.insert(EPSILON); } } visiting[X] = false; calculated[X] = true; firstSets[X] = result; return result; }

代码逻辑上，三个关键点值得细看。visiting标记解决的是递归环问题，没有它，遇到A -> B、B -> A这种文法会直接栈溢出。canDeriveEmpty标志控制“什么时候把 ε 放进去”，只有右部所有符号都能推导出 ε，该产生式才贡献 ε。而calculated缓存保证每个非终结符的 FIRST 集只算一次，性能上是 O(产生式数量 × 右部长度) 的量级，对课设层级的文法完全够用。这是一个典型的“用空间换正确性”的写法，在 get_first.cpp 里属于高频套路。

3.2 FOLLOW 集迭代计算：必须重复扫到集合不再增长

FOLLOW 集没法简单地递归算，因为A -> αBβ中 FOLLOW(B) 的一部分来自 FOLLOW(A)，而 FOLLOW(A) 又可能依赖别的产生式，互相引用形成一个固定点问题。get_follow.cpp 用的常见方法是初始化后反复扫描全部产生式，直到一轮下来集合没有变化才停。开始前记得把结束符#（或$）放进开始符号的 FOLLOW 集，这是很多课设忘掉的第一步。

// get_follow.cpp 的迭代主循环（简化） bool changed = true; g_follow[g_startSymbol].insert(END_MARKER); // 先把 # 放入 S 的 FOLLOW 集 while (changed) { changed = false; for (auto& prod : g_productions) { Symbol A = prod.left; // A -> α B β for (size_t i = 0; i < prod.right.size(); i++) { Symbol B = prod.right[i]; if (!IsNonTerminal(B)) continue; // 只对非终结符做 // 情况 1: 找 B 后面的符号 β bool betaCanBeEmpty = true; for (size_t j = i + 1; j < prod.right.size(); j++) { Symbol C = prod.right[j]; for (Symbol s : g_first[C]) { if (s != EPSILON) { if (g_follow[B].insert(s).second) changed = true; } } if (g_first[C].find(EPSILON) == g_first[C].end()) { betaCanBeEmpty = false; break; } } // 情况 2: β 为空或能推空，把 FOLLOW(A) 并入 FOLLOW(B) if (betaCanBeEmpty) { for (Symbol s : g_follow[A]) { if (g_follow[B].insert(s).second) changed = true; } } } } }

这里的changed标志是迭代算法的标准写法，表现为事件驱动：只有出现新元素时，下一轮扫描才有意义。两个循环里，外层遍历所有产生式，内层遍历右部每个位置，判断“当前位置后面的符号序列 β 是否能推导出 ε”。这一点很关键，因为A -> αB这种出现在右部末尾的情况，等价于 β 为空，FOLLOW(B) 直接继承 FOLLOW(A)。如果你在调试时发现某个非终结符的 FOLLOW 集永远算不全，九成是betaCanBeEmpty处理有误，把“后面没有符号”和“后面有终结符”两种情况混为一谈。

3.3 ε 与 nullable：一个符号有没有可能“消失”

FIRST 和 FOLLOW 都离不开 ε 的特殊处理，项目里把这种能力单独说成“nullable 判断”。一个非终结符 nullable，意味着它能推导出空串，这时它的 FIRST 集里必须出现 EPSILON，同时它在 FOLLOW 计算时会把自己的 FOLLOW 集“传递”给前一个符号。整个项目有三处需要 nullable 判断：算 FIRST 时决定贡献不贡献 ε，算 FOLLOW 时决定是否把 FOLLOW(A) 并入前面符号，以及最后填预测表时决定是否按 FOLLOW 规则填表。

三种集合的职责区别可以这样记：

需要注意，LL(1) 分析器只有一个输入符号的“视野”，所以 FIRST 和 FOLLOW 里的终结符必须是无冲突的。如果某个符号既出现在 FIRST(A) 里又被预测表放在别的产生式，执行分析时就会不知道下一步做什么。这也是下一章预测表生成时要做冲突检测的原因。

4. 预测分析表与冲突检测：从集合到自动判定的关键一步

有了 FIRST 和 FOLLOW，下一步就是生成 M 表——一个二维结构，行是非终结符，列是终结符（外加结束符 #）。generator.cpp 做这件事的规则非常机械，但细节一错就全错。填错一个格子，分析器就会在某个输入串上给出莫名其妙的错误，而且很难察觉。

4.1 填预测表的规则：FIRST 里放候选、FOLLOW 里放 ε 候选

对每条产生式A -> α，按照两条规则填表：

• 对a ∈ FIRST(α)且a != ε，在表M[A][a]填入产生式A -> α；
• 如果ε ∈ FIRST(α)，即 α 可空，则对b ∈ FOLLOW(A)，在表M[A][b]填入A -> α。

如果 FIRST(α) 里有 ε，产生式A -> α相当于“当输入符号出现在 A 的 FOLLOW 集时，把 A 归约为空串”，这是所有 LL(1) 分析器处理空产生式的核心手段。这步写成 C++ 特别简短，但有两个容易犯的经典错误：一是把ε当成终结符填进表里；二是忘记查 FOLLOW(A)，直接填到所有列。

// generator.cpp 中填表核心逻辑（简化） // table 用 vector<vector<Production*>> 表示，行是非终结符，列是终结符编号 for (auto& prod : g_productions) { Symbol A = prod.left; set<Symbol> firstAlpha = CalcFirstOfSequence(prod.right); // 整个右部的 FIRST bool canEmpty = (firstAlpha.find(EPSILON) != firstAlpha.end()); for (Symbol a : firstAlpha) { if (a == EPSILON) continue; // ε 不可能成为真正的输入符号 InsertIntoTable(A, a, prod); // FIRST 规则 } if (canEmpty) { for (Symbol b : g_follow[A]) { InsertIntoTable(A, b, prod); // FOLLOW 规则，只有右部可空时才触发 } } }

CalcFirstOfSequence是对产生式右部整个符号序列求 FIRST，逻辑与第 3 章的 GetFirst 类似，区别在于它按序列顺序逐符号取集合，只有前一个符号可空才继续往后取。这个函数在 get_first.cpp 或 generator.cpp 里都可以放，属于被复用的工具函数。参数上要注意InsertIntoTable不能直接覆盖写入，必须先查目标格子是否已有内容，这与下一节冲突检测直接相关。

4.2 冲突检测：同一格子第二次写入就是警告

填表过程中，如果一个格子M[A][a]已经被填过一条产生式，又要写入另一条，说明文法在输入符号 a 处存在二义选择，文法不是 LL(1)。这时的正确做法是保留第一次写入的记录，同时打印“冲突”提示，而不是静默覆盖。静默覆盖是很多实现的首个坑——程序能跑，预测表也能输出，但输出实际是错的，分析器会在这类输入上随意选一条路径。

// 冲突检测的插入函数写法 void InsertIntoTable(Symbol A, Symbol a, Production& prod) { auto& cell = table[A][a]; if (cell != nullptr) { // 已有入住者，说明冲突：两条产生式都声称能处理这个输入符号 cout << "Conflict at M[" << g_symbol2name[A] << "][" << g_symbol2name[a] << "] between:" << endl; cout << " " << ProductionToString(*cell) << endl; cout << " " << ProductionToString(prod) << endl; g_hasConflict = true; return; } cell = &prod; // 首次写入，记录该格子的产生式 }

g_hasConflict是一个全局标记，冲突检测结束后由 main.cpp 读取。如果为真，说明输入文法不是 LL(1)，整个项目仍然可以继续输出预测表，但主程序应当在最终结果里明确给出“not LL(1)”的判定。这对课设答辩非常重要——你的程序不是简单的“能跑就行”，而要能解释“为什么这套文法不行”。当老师把一套非 LL(1) 文法丢到程序里，程序能指出冲突位置比报一个笼统的错误信息要高级得多。

4.3 从分析表到动作：analyze.cpp 主循环怎么跑

预测表生成完毕，analyze.cpp 开始执行真正的表驱动分析：维护一个分析栈和剩余输入缓冲区，初始时栈里是#和开始符号 S，输入串尾部放#作为结束符。每一步取栈顶符号 X 和当前输入符号 a：

• 若 X 和 a 都是#，接受输入串，分析成功；
• 若 X 是终结符且 X == a，弹出 X，读取下一个输入符号；
• 若 X 是非终结符，查表M[X][a]，找到产生式则弹出 X 并把右部逆序压栈，找不到则报语法错误。

// analyze.cpp 中的主循环（简化） stack<Symbol> stk; stk.push(END_MARKER); // 栈底 # 先入 stk.push(g_startSymbol); // 开始符号入栈 size_t pos = 0; while (!stk.empty()) { Symbol X = stk.top(); Symbol a = inputTokens[pos]; if (X == END_MARKER && a == END_MARKER) { cout << "ACCEPT" << endl; return; } if (X == a) { // 栈顶是终结符且匹配，弹栈并前移 stk.pop(); pos++; continue; } if (IsNonTerminal(X)) { Production* prod = table[X][a]; if (prod == nullptr) { cout << "Syntax error at token " << g_symbol2name[a] << endl; return; } stk.pop(); for (auto it = prod->right.rbegin(); it != prod->right.rend(); ++it) { if (*it != EPSILON) stk.push(*it); // ε 不压栈 } } else { cout << "Unexpected token " << g_symbol2name[a] << endl; return; } }

主循环里最容易被忽略的细节是“ε 不压栈”：产生式右部如果包含空串标记 EPSILON，弹出左部后不需要把任何东西压进栈，直接进入下一步即可。如果错误地把 EPSILON 也压进栈，程序中就会出现一个永远不会匹配任何输入符号的“幽灵符号”。pos是输入缓冲区下标，每次终结符匹配成功后加一，但扫描错误或归约时不动，这个“按需推进”的行为就是 LL(1) 分析的典型特征。表驱动主循环写好后，整个项目的闭环就完成了：输入文法 → 算出集合 → 检测冲突 → 生成表 → 实际分析输入串。

5. 避坑与常见问题：实现 LL(1) 分析器最容易翻车的五个细节

在帮人调课设代码的过程中，我反复遇到一些同样的报错和“玄学结果”。这些坑少有算法层面的，几乎全是细节层面。整理五条我个人觉得最值得提前预防的，避雷比补救省时间。

5.1 左递归没消除，程序直接递归爆栈

现象：程序读入E -> E + T | T这类文法后，get_first.cpp 直接抛 stack overflow 异常，或运行时卡死。

原因：预处理阶段没有正确消除左递归，或只处理了直接左递归而遗漏了间接左递归，比如A -> B、B -> A成环。FIRST 集递归算法遇到这种情况后，visiting标记没有正确拦截（或者访问标记只在部分路径设置），递归永远无法收敛。

解决：先确认 preprocess.cpp 里对直接左递归的改写是否完整；其次，在 GetFirst 的入口处必须第一时间检查visiting并返回空集。如果问题仍存在，临时在 GetFirst 里加一个递归深度计数器，超过 100 次直接报错退出，定位到具体是哪个非终结符引发了环路。最常见的真正原因是消除左递归时新生成的辅助非终结符没有注册进符号表，导致后续计算拿到无效编号。

5.2 FOLLOW 集漏了 #，所有带 ε 的产生式全变“不可达”

现象：分析一个输入串时，所有基于空产生式的判断全部失败。比如文法允许S -> A、A -> ε，但输入串中 A 应该消失的位置都报语法错误。

原因：FOLLOW 计算之前忘记把结束符#初始化到开始符号的 FOLLOW 集中。没有这个起手式，开始符号的 FOLLOW 为空，所有向上传递 FOLLOW 的规则全军覆没。从代码上看，就是少了g_follow[g_startSymbol].insert(END_MARKER)这一行。

解决：在 get_follow.cpp 的迭代循环开始前强制检查一遍，确认 END_MARKER 已经存在于开始符号的 FOLLOW 集合里。还有一种隐蔽情况：输入文法使用$而非#作为结束符，而代码里硬编码了#，读入的文法一旦没有#，整个 FOLLOW 链都会断。建议把结束符定义成一个常量，统一替换。

5.3 全局变量没复位，换一个文法后集合还在“叠加”

现象：main.cpp 先分析文法 1 再分析文法 2，第二个文法的 FIRST/FOLLOW 集里出现一堆第一个文法的符号，结果完全错乱。

原因：common_header.h 里声明的全局 map 和 vector，在第二次执行时没有清空。g_first、g_follow、g_productions里残留了上一次的文法数据，而calculated标记又没有重置，部分旧结果被当作新结果直接命中缓存。

解决：在 gpprocess 之前做一个ResetAll()函数，把所有全局容器 clear 掉。具体来说，g_first.clear()、g_follow.clear()、g_productions.clear()、g_symbol2name.clear()，同时把 FIRST 计算里的calculated和visiting一并清掉。这一步看似只影响“连续跑两个文法”的场景，但很多课设的测试环节会循环读取多个测试文件，没做复位时前一个文法的残留数据会污染后面所有结果，排查起来非常累。

5.4 文法文件里的 \r 和 BOM，第一行就读废了

现象：在 Windows 环境下编写的 .txt 文法文件，用 VSCode 配置好 C/C++ 环境跑起来，程序解析第一行就报“符号不存在”或产生式左部为空。

原因：Windows 记事本默认使用 CRLF 换行，文件开头还可能带 UTF-8 BOM 头。如果用getline读取，每一行的末尾会残留\r，\r被当成符号名的一部分；BOM 则会让第一行的第一个字符变成不可见乱码。

解决：预处理时对每行做 trim，去掉行首行尾空白、\r、\n和 BOM 标记。一个通用写法是读取后统一替换：检查第一个字符是否为\uFEFF并剥离，然后对每一行末尾的\r做pop_back。这个问题在 Linux 下测评时不会暴露，但一旦把项目拷贝到 Windows 上，或者反过来，文格式换一下就会瞬间翻车，属于生态位差异导致的经典课设血泪经验。

5.5 把“语法错误”报成“程序崩了”：表驱动主循环的边界处理

现象：输入串不是合法语句时，程序不是输出“syntax error”，而是直接抛出 vector 越界、空指针访问，或者在table[X][a]查到空引用后崩溃。

原因：analyze.cpp 主循环里对“表项为空”的情况没有提前检查，直接访问prod->right。预测分析表的每个格子确实是nullptr，但代码在if (prod == nullptr)之前就解引用了指针。另一个常见越界点是输入缓冲区读取：inputTokens[pos]在#还没被推进时就可能已经越界。

解决：第一，查表之后先判空再解引用，任何nullptr都作为语法错误处理，绝不能想当然跳过；第二，input 缓冲区末尾始终保留#，并且每次访问前检查pos是否指向末尾；第三，把错误信息写成“Error: unexpected token X at position N”，带行号或位置信息比单纯说“error”更能帮你定位。这五个坑调完，整个项目基本能做到“玄学”全部清零——出的问题都能用代码解释清楚，而不是靠重新编译碰运气。

6. 验证分析器是否可信：测试文法、单步日志与回溯定位技巧

程序跑通了一组输入，并不代表所有输入都正确。我这里有一套个人的验收流程，专门验证“程序到底是不是真的 LL(1) 分析器，还是碰巧分析对了”。

第一招，构造三类必测文法：一个“标准 LL(1) 算术表达式文法”，一个“故意带左因子冲突的文法”，一个“必须靠 FOLLOW 集才能填表的含 ε 文法”。算术表达式文法大致形如：

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

这套文法每个环节都照顾到：需要 FIRST 集，需要 FOLLOW 集处理 E' 和 T' 的 ε 产生式，而且 F -> ( E ) | id 两个候选的 FIRST 集不相交，能稳定通过 LL(1) 判定。如果程序把这套文法分析正确，核心算法就没大问题。再跑一个S -> id = S | if ( E ) S else S的混合文法，测试带关键字和括号的输入串。

第二招，打开单步日志。main.cpp 里设计一个logLevel参数，设为 1 时，analyze.cpp 每步打印三行信息：当前分析栈内容、剩余输入串、执行的动作（“match id”“reduce by E -> T E’”这样的文字）。这样输入id + id * id时，能逐个步骤核对每一步是否符合推导预期。没有这一步，你只能看到最终 ACKEPT 或 REJECTED，中间哪里错了完全是个黑匣子。

第三招，手工对照预测表。生成器输出的表格行和列可能很长，别只盯着屏幕滚动。用 test_print.cpp 输出的文本，复制到 Excel 里做成表格，挑一列非终结符手工演算几个关键格子：M[E'][+]应当是E' -> + T E'，M[E'][#]应当是E' -> ε。这两个格子一个来自 FIRST 规则，一个来自 FOLLOW 规则，任何一个错了都说明前面集合计算有问题。从那以后我每次跑课设版 LL(1) 分析器，都强制走一遍三件套：跑标准文法、开单步日志、手工抄五个关键格子对照，五分钟能定位九成的问题。希望这份拆解能帮你把编译原理这门课从“背书”变成“真能写出来”的实战体验，也希望你拿到的这套 C++ 实现能踏踏实实跑出分析表和分析结果。

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