递归下降解析器是一组相互调用的C++函数，每个函数对应一条语法规则，共享一个封装token流的类，通过前瞻一个token并手动推进位置来实现解析。
递归下降解析器的核心结构长什么样
递归下降不是某种库或框架，它就是一组相互调用的 C++ 函数，每个函数对应一条语法规则。比如 expr() 解析表达式，term() 解析项，factor() 解析因子——这些函数名直接映射 BNF 中的非终结符。
关键在于：每个函数只向前看一个 token（即“前瞻一个”），靠这个 token 决定走哪条分支。这意味着你必须手动维护一个 current_token，并在每次匹配成功后调用 next_token() 推进。
常见错误现象是函数没推进 token 就返回，导致无限循环或跳过输入；或者推进了但没检查是否到结尾，引发越界访问。
- 必须用一个类封装 token 流，包含
m_tokens和m_pos，所有解析函数共享同一实例 - 每个函数开头先检查
current_token.type == expected_type，不匹配就报错或回退（如果支持回溯） - 匹配成功后立刻调用
consume()（即m_pos++），不能靠调用方负责
expr → expr '+' term
- 原规则
expr → term | expr '+' term | expr '-' term→ 改成expr → term { ('+' | '-') term } - 对应代码中，
expr()先调一次term()得到初始值，再用 while 循环反复检查current_token.type == PLUS || MINUS - 每次匹配操作符后 consume，再调
term()，然后做实际运算
这样既避免栈爆炸，又保持了左结合性。别试图在 C++ 里模拟回溯或用 std::function 缓存状态来绕过——性能差、逻辑乱、调试难。
什么时候该用 std::variant 而不是继承+虚函数
如果你的 AST 节点类型不多（比如 BinaryOp、Number、Identifier），用 std::variant 更轻量、更安全。
继承方案看似“面向对象”，但容易踩坑：忘了定义虚析构函数、误用裸指针管理生命周期、RTTI 开销不可控。而 std::variant 强制你在访问前做模式匹配，编译期就能拦住未覆盖的 case。
使用场景很明确：AST 构建完成后要遍历执行或打印，且节点种类稳定（少于 10 种）。这时 std::visit 配合 lambda 是最直白的写法。
- 不要用
dynamic_cast做运行时类型判断，那是给多态接口用的，不是给 AST 的 - 如果节点需要携带位置信息（
line,col），直接塞进每个 struct 里，别搞“基类带位置字段”那一套 -
std::variant的构造开销几乎为零，但注意别在循环里反复拷贝大 variant
using Expr = std::variant<number binaryop identifier>;
Expr parse_expr() { /* ... */ }
</number>
错误恢复怎么做才不至于一崩到底
递归下降默认是“悲观式”解析：一个 token 错，后面全乱。但用户写代码时打错一个括号，你不该直接退出，而应尝试跳过坏 token、同步到下一个合理起点（比如 ; 或 }）。
关键是定义“同步集”（synchronizing set）：对每个函数，明确哪些 token 可以作为恢复锚点。比如 stmt() 的同步集通常是 SEMI、RBRACE、IF、WHILE。
- 不要一遇到错误就 throw —— 异常打断控制流，让恢复逻辑难以插入
- 在每个顶层函数（如
parse_function()）入口加保护：若current_token是明显非法值（如INVALID），先调用skip_to_sync({SEMI, RBRACE}) -
skip_to_sync就是 while 循环：只要current_token.type不在集合里，就consume()
性能影响很小，但用户体验差别巨大。没人想每次少打个逗号就得重输整段。
真正麻烦的是错误嵌套：比如在 expr() 里出错，跳出去后又在 stmt() 里撞上另一个错。这时候同步集得有层级感——外层比内层更宽松。这点容易被忽略，结果是报错位置飘忽、信息错位。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
