老实说，我一度觉得解释器模式是那种“面试讲得很热闹、项目里根本用不上”的设计模式。直到有一次做规则引擎，后端需要把业务人员填写的字符串公式安全地算出来，不能调用系统里现成的动态执行能力，也没多少空间去引入新的脚本依赖。那周我重新翻开设计模式里关于 C++ 解释器模式的那一章，发现课本写法和真实工程之间隔着一整层“用什么数据结构、谁来管理内存、优先级怎么处理、错误怎么抛”的细节。这篇文章不想复述书本定义，而是用一个很小的表达式语言 MiniCalc 作为线索，从文法定 AST、再到递归下降分析和求值，和你一起把解释器模式在 C++ 中的完整落地过程过一遍。

MiniCalc 支持四则运算、括号、一元负号、变量赋值和 print 输出，规模不大，但足够覆盖解释器模式里最核心的语法树设计思路。适合刚开始接触设计模式、想在 C++ 项目里内置自定义表达式或规则配置、以及读了不少理论却不知道 parser 从哪下手的读者。

如果你只是想快速计算字符串，也许用现成库更省事；但如果你想搞懂“自定义语言”究竟是怎么变成一棵可以被遍历、打印、优化的树结构，那下面这些步骤大概率能帮你把概念串成一条能用的链路。

1. 解释器模式不是面试题：先搞清楚它真正要解决的问题

1.1 我在什么场景下真的需要写一个解释器

解释器模式适合的场景，本质是“规则经常变化、但语法结构相对稳定”。最典型的就是一套小型的规则表达式：活动折扣、绩效考核公式、自动告警阈值、积分抵扣规则。这些规则如果直接在 C++ 里硬编码，每改一次商务规则都要改代码、走构建、重新发布；如果用一套自定义的小语言把它们写成配置，让程序启动时解释执行，改动成本就低很多。

这一点对很多人来说可能不太直观，尤其没接触过领域建模的读者会问：直接存 JSON 配置不行吗？当然可以。JSON 能存数据，却很难表达可执行的逻辑结构。比如“总金额超过 1000 时打 8 折，否则原价”，用 JSON 表达要么塞一堆嵌套字段，要么干脆存一段字符串。而解释器模式给字符串定义了一套合法语法，并在运行期把它当成真正的“代码”执行，只不过这套代码受你控制、不会有通用脚本引擎那么大的权限。

我当时需要处理的规则文本长这样：

text复制amount * 0.08 - fixedCost

如果只做简单字符串替换，很难处理变量名、乘除优先级、括号这些结构；如果直接调通用脚本来 eval，安全边界、依赖体积、启动性能又都是新问题。最后我选的方案就是按解释器模式写出自己的迷你文法，这让“逻辑文本”变成程序里可导航、可调试、可扩展的一棵树。

1.2 三种替代方案花了多少钱，解释器模式到底赢在哪

在决定自写解释器之前，最稳妥的做法是先做选择题，避免为了“用模式而用模式”。我做过的技术对比基本是这样：

选择手写解释器模式有一个很实际的收益：中间产物 AST 是可以复用的。你不仅可以靠它执行，还能在它上面做安全白名单检查、子表达式替换、性能分析、甚至生成调试信息。一个只做字符串替换的函数没有这种扩展能力，这就是解释器模式最大的“护城河”。

1.3 GoF 解释器模式在 C++ 里的习惯用法对照

设计模式书里经常提到四个角色：Context、AbstractExpression、TerminalExpression、NonterminalExpression。刚接触的时候容易把这些术语背下来，但不知道怎么映射到代码。

如果把 MiniCalc 映射过去，我的习惯是这样：

• AbstractExpression：对应抽象类 ExprNode，所有表达式节点都有 eval 能力。
• TerminalExpression：对应 NumberNode 和 VariableNode，它们是表达式树的叶子。
• NonterminalExpression：对应 BinaryNode 和 UnaryNode，它们持有子节点，学会递归求值。
• Context：对应 EvalContext，保存变量表和输出位置，在求值过程中共享。

这段对应关系能帮你理解：解释器模式本质上不是在教你如何“读字符串”，而是在告诉你，把读字符串后产出的树做成可递归求值的对象，这样一个看似复杂的解释过程就被拆成了每个节点只负责自己那点事的小步递归。C++ 里唯一要额外花心思的，是这些节点对象如何安全地组合起来。这直接决定了 AST 数据结构要不要暴露给调用方、递归求值会不会栈溢出、以及未来扩展比较语句时改动范围有多大。

2. 为 MiniCalc 定文法：表达式的优先级必须写进数据结构

2.1 一个小语言的文法长这样

在写任何 node 类之前，建议先把文法画出来。文本或者注释都行，只要你自己和别人能看懂。MiniCalc 的文法定义如下：

text复制program    := statement*
statement  := 'print' expression ';'
            | identifier '=' expression ';'
            | expression ';'
expression := term (('+' | '-') term)*
term       := factor (('*' | '/') factor)*
factor     := number
            | identifier
            | '(' expression ')'
            | '-' factor

这里最关键的是“优先级靠文法层级体现”。加减法在更高一层的 expression 规则里，乘除法在 term 规则里，而括号和最贴近原子的 factor 是最底层。你在写 parser 时，哪一层的调用深度越深，它就越先被计算。

提示：不要试图把所有计算规则平铺在一个 parseExpression 函数里处理。优先级如果处理错了，后面所有的表达式求值结果都会跟着错，而且这种错还很难排查，因为单个表达式看起来可能很正常。

2.2 AST 节点怎么设计才不给自己挖坑

AST 一旦建好，后续所有阶段都在跟它打交道，所以节点要不要区分表达式和语句，是我每次都很慎重的事。我见过不少读者一开始只设计一个 ExprNode，连 print 也硬塞成“会打印的表达式”，结果语义混乱，后面加 if、for 之类的语句时无从下手。

MiniCalc 把节点分成两层：

cpp复制struct EvalContext;

class ExprNode {
public:
    virtual ~ExprNode() = default;
    virtual double eval(EvalContext& ctx) const = 0;
};

class NumberNode final : public ExprNode {
public:
    explicit NumberNode(double value) : value_(value) {}
    double eval(EvalContext&) const override { return value_; }
private:
    double value_;
};

class VariableNode final : public ExprNode {
public:
    explicit VariableNode(std::string name) : name_(std::move(name)) {}
    double eval(EvalContext& ctx) const override;
private:
    std::string name_;
};

class BinaryNode final : public ExprNode {
public:
    BinaryNode(char op,
               std::unique_ptr<ExprNode> left,
               std::unique_ptr<ExprNode> right)
        : op_(op), left_(std::move(left)), right_(std::move(right)) {}
    double eval(EvalContext& ctx) const override;
private:
    std::string ToString() const;
    char op_;
    std::unique_ptr<ExprNode> left_;
    std::unique_ptr<ExprNode> right_;
};

语句层我通常单独建一个基类：

cpp复制class StmtNode {
public:
    virtual ~StmtNode() = default;
    virtual void execute(EvalContext& ctx) const = 0;
};

class PrintStmt final : public StmtNode { /* ... */ };
class AssignStmt final : public StmtNode { /* ... */ };
class ExprStmt final : public StmtNode { /* ... */ };

之所以区分表达式和语句，是因为表达式有“求值结果”、语句只是“产生副作用”，比如打印或赋值。把它们放在同一棵节点树里虽然也能跑，但会让后来的能力扩展很别扭。假如以后想支持 if 条件分支，条件部分应该是表达式，分支体则应该是语句列表。这个分层从最开始就值得划清楚。

2.3 为什么是 unique_ptr 而不是 shared_ptr 或裸指针

C++ 写解释器模式最常见的争议就是节点指针的持有方式。我的选择是：树内所有权用 unique_ptr，调用方只在外面持有根节点或语句列表。原因有三点：

第一，AST 是严格的树结构，一个子节点只会有一个父节点，这天然符合 unique_ptr 的独占所有权。第二，shared_ptr 需要维护引用计数，而求值过程本身已经有很多虚函数调用，没必要再为每个子节点增加一个原子变量的开销。第三，裸指针虽然写起来快，但一旦 parse 过程在某一步抛出异常，所有已经分配出来的节点如果没有智能指针管理，立刻就会内存泄漏。

这种写法最大的后续收益是：Parser 里返回节点时直接 return std::make_unique(...)，天然支持 move 语义，不需要写复杂的拷贝逻辑。缺点是 AST 一旦建立就不方便浅拷贝共享，但是解释器场景下本来也不常需要拷贝整棵树，所以限制可以接受。

注意：如果一个节点要被子表达式复用，比如某个函数体被多次调用，那就该另换 shared_ptr 或者做深拷贝设计。大多数解释器不需要这种优化，先用 unique_ptr 把问题的复杂度压到最低，比任何过早优化都重要。

3. 词法分析与递归下降 Parser：把字符串变成树

3.1 Token 设计：把“怎么看懂文本”和“怎么组织逻辑”分开

解析一个表达式绝不能一步到位。第一步是词法分析，也就是把字符串拆成 token 流；第二步才是语法分析，把 token 组织成 AST。Token 流的出现让 parser 只关注结构规律，不必一个字符一个字符地处理空白、数字小数点、变量名。

MiniCalc 的 Token 设计如下：

cpp复制enum class TokenKind {
    Number, Identifier,
    Plus, Minus,
    Star, Slash,
    LParen, RParen,
    Assign, Semicolon,
    Print, End
};

struct Token {
    TokenKind   kind;
    std::string text;
    double      value = 0.0;
    int         line  = 0;
};

词法分析器的核心逻辑并不复杂。跳过空白，然后根据当前字符判断类型：数字字符进入数字分支，字母或下划线进入标识符分支，运算符直接生成对应 Token。print 这种关键字可以在词法阶段识别成独立 TokenKind，也可以在 parser 看到 Identifier 并且 text 是 "print" 时再处理。我比较喜欢在词法阶段就识别关键字，因为后续 parser 的判断会更直观，也可以避免变量名恰好叫 print 时产生二义性。

3.2 parseProgram / parseStatement 的骨架

Parser 的骨架一般是一个持有 token 流和当前下标的类。MiniCalc 的顶层解析循环大概是这样的：

cpp复制std::vector<std::unique_ptr<StmtNode>> Parser::parseProgram() {
    std::vector<std::unique_ptr<StmtNode>> stmts;
    while (!check(TokenKind::End)) {
        stmts.push_back(parseStatement());
    }
    return stmts;
}

parseStatement 负责判断当前语句到底是 print、赋值还是普通表达式语句。一个容易踩的坑是赋值语句只能在语句顶层解析，不要在 parseExpression 内部偷偷识别赋值号。这样写虽然会让 a = b = 1 这类链式赋值变得不支持，但它能保持表达式层级的简洁，MiniCalc 这种小语言没必要一上来就支持右结合赋值链。

普通标识符既可以作为变量读取，也可以作为赋值目标，所以 parser 需要向前多看一个 token 来决定分支：

cpp复制std::unique_ptr<StmtNode> Parser::parseStatement() {
    if (match(TokenKind::Print)) {
        auto expr = parseExpression();
        expect(TokenKind::Semicolon, "expected ';' after print expression");
        return std::make_unique<PrintStmt>(std::move(expr));
    }

    if (check(TokenKind::Identifier) && peekNext().kind == TokenKind::Assign) {
        Token name = advance();
        advance(); // 消耗 '='
        auto expr = parseExpression();
        expect(TokenKind::Semicolon, "expected ';' after assignment");
        return std::make_unique<AssignStmt>(std::move(name.text), std::move(expr));
    }

    auto expr = parseExpression();
    expect(TokenKind::Semicolon, "expected ';'");
    return std::make_unique<ExprStmt>(std::move(expr));
}

这里的 match、check、advance、expect 都属于 parser 的小工具函数，作用分别是“尝试匹配并消费”“只看当前 token”“前进一个 token”“如果没有期望的 token 就抛错”。把异常处理集中在这几个小函数里，后面每个规则函数写起来都会很干净。

3.3 优先级处理：加减法、乘除法、一元负号谁在下层

优先级处理是递归下降解析器最值得细看的地方。对应到代码，parseExpression 调 parseTerm，parseTerm 调 parseFactor。加减法的规则函数只负责识别加减号，并假设自己解析出来的左右操作数已经是乘除没有问题了。反过来，乘法函数也假设左右边的 factor 已经能正确处理括号和一元负号。

cpp复制std::unique_ptr<ExprNode> Parser::parseExpression() {
    auto left = parseTerm();
    while (check(TokenKind::Plus) || check(TokenKind::Minus)) {
        Token op = advance();
        auto right = parseTerm();
        left = std::make_unique<BinaryNode>(
            op.kind == TokenKind::Plus ? '+' : '-',
            std::move(left), std::move(right));
    }
    return left;
}

std::unique_ptr<ExprNode> Parser::parseTerm() {
    auto left = parseFactor();
    while (check(TokenKind::Star) || check(TokenKind::Slash)) {
        Token op = advance();
        auto right = parseFactor();
        left = std::make_unique<BinaryNode>(
            op.kind == TokenKind::Star ? '*' : '/',
            std::move(left), std::move(right));
    }
    return left;
}

这种“循环而不是左递归”的写法，是递归下降 parser 里最常见的落点。如果你参考教科书直接写 parseExpression: parseExpression + parseTerm，那会陷入无限递归，因为函数第一步又调用了自己。实际工程中，左结合运算符都用 while 循环处理，避免左递归而不会改变结合性。

parseFactor 要处理四种情况：数字、变量、括号表达式、一元负号。

cpp复制std::unique_ptr<ExprNode> Parser::parseFactor() {
    if (match(TokenKind::Minus)) {
        auto operand = parseFactor();
        return std::make_unique<UnaryNode>('-', std::move(operand));
    }
    if (match(TokenKind::Number)) {
        return std::make_unique<NumberNode>(previous().value);
    }
    if (match(TokenKind::Identifier)) {
        return std::make_unique<VariableNode>(previous().text);
    }
    if (match(TokenKind::LParen)) {
        auto expr = parseExpression();
        expect(TokenKind::RParen, "expected ')'");
        return expr;
    }
    throw ParseError("unexpected token in factor", peek().line);
}

到这里，你会发现 AST 的结构其实就是由 parser 的调用图和 while 循环“雕刻”出来的。3 + 4 * 2 会被解析成 Binary('+', Number(3), Binary('*', Number(4), Number(2)))。所有优先级的秘密都藏在 parseExpression 调 parseTerm、parseTerm 调 parseFactor 的层级关系里。

3.4 出错处理：位置信息比具体错误文案更重要

解析器最容易让人崩溃的地方不是逻辑写不出来，而是报错信息完全没法定位。如果你只抛 std::runtime_error("parse error")，一旦表达式变长，使用者根本不知道哪个字符写错了。

我通常在每个 Token 上保存行号，ThreadLocal 式的错误类型里带行号，甚至还可以带“当前解析到了哪个 token”的提示信息：

cpp复制class ParseError : public std::runtime_error {
public:
    ParseError(const std::string& msg, int line)
        : std::runtime_error(msg + " at line " + std::to_string(line)) {}
};

解析错误要尽早抛。不要试图容忍多余或缺失的符号，比如在 print 3 + 4; 后如果漏了分号，宁可让 parser 立刻报错“expected ';'”，也不要在后面靠某种启发式硬撑过去。解释器模式里，明确失败永远比含糊通过更受欢迎，因为错误的输入如果被错误地执行，结果比“没执行”更危险。

4. 求值器：虚函数是最务实的选择而不是倒退

4.1 Environment：上下文 Context 到底用来装什么

表达式节点本身不能访问外部变量，所以求值时需要传入 EvalContext。这个对象在运行时承担“上下文”的角色，类似 GoF 里的 Context。MiniCalc 的 EvalContext 只需要两样东西：变量表和输出流。

cpp复制struct EvalContext {
    std::unordered_map<std::string, double> vars;
    std::ostream* output = &std::cout;
};

看起来很简单，但实际扩展空间很大。未来如果支持函数，可以在 EvalContext 里增加函数表；如果支持局部作用域，可以改成指向父级的 parent 指针；如果希望打印内容不直接落到 stdout，而收集到字符串，也可以把 output 换成可替换的流对象。这个共享上下文是我们唯一能携带“当前执行环境”的地方。

4.2 在节点上实现 eval：别把所有逻辑都塞进 Context

实现求值器有两种主流做法：一种是把 eval 做成每个节点自己的虚函数，另一种是把节点数据暴露给一个独立的 Visitor 对象。MiniCalc 这种规模，我建议用虚函数。为什么？

因为节点类型不多，每个节点自己实现 eval，代码会非常集中。NumberNode 返回 value，VariableNode 查表，BinaryNode 先求左右再根据 op 计算。如果改用 Visitor 模式，虽然“新增操作不用改节点类”很诱人，但为了 6 类节点写一套 visitor 基础设施，在小范围内其实是净成本。

让我补上两个核心节点的求值实现。VariableNode 需要查变量表，如果没有找到变量就抛错：

cpp复制double VariableNode::eval(EvalContext& ctx) const {
    auto it = ctx.vars.find(name_);
    if (it == ctx.vars.end()) {
        throw RuntimeError("undefined variable: " + name_);
    }
    return it->second;
}

BinaryNode 的核心是先递归求值左右子节点，再做运算：

cpp复制double BinaryNode::eval(EvalContext& ctx) const {
    double lhs = left_->eval(ctx);
    double rhs = right_->eval(ctx);
    switch (op_) {
        case '+': return lhs + rhs;
        case '-': return lhs - rhs;
        case '*': return lhs * rhs;
        case '/':
            if (rhs == 0.0) {
                throw RuntimeError("division by zero");
            }
            return lhs / rhs;
        default:
            throw RuntimeError("unknown binary operator");
    }
}

这里有个很容易被忽略的小点：除法必须先把 rhs 存出来再判断是否为零。如果你直接把 right_->eval(ctx) 写进表达式里，又不小心调用两次，不仅会重复求值，一旦变量节点有副作用或者查表失败会引发定位困难。虽然 MiniCalc 没有副作用，但养成“每个子节点只求值一次”的习惯，是以后扩展到有副作用语言时保护自己最好的方式。

4.3 运行时错误：未定义变量和除零不能静默

解释器最怕出现“程序没崩溃，但结果不对”的静默错误。变量名写错了，如果求值器只是返回某个默认值，业务人员可能会把错误规则上线好几天。因此在 VariableNode 和除法逻辑中，我选择直接抛异常，让上层捕获后给出清晰的错误描述，而不是默默返回 0 或 NaN。

与解析阶段的异常不同，求值阶段的错误往往是运行期才知道的，比如变量不存在、除数为零、递归深度超限。这些异常应该被解释器入口捕获，并统一打印出“是哪个表达式、哪一步出问题”，而不是让调用方看到一堆裸奔的 C++ 堆栈。

语句层执行也需要注意顺序。PrintStmt 执行时先求值表达式，再写输出：

cpp复制void PrintStmt::execute(EvalContext& ctx) const {
    double result = expr_->eval(ctx);
    if (ctx.output) {
        *ctx.output << result << "\n";
    }
}

AssignStmt 执行时把赋值目标写入变量表：

cpp复制void AssignStmt::execute(EvalContext& ctx) const {
    double value = expr_->eval(ctx);
    ctx.vars[name_] = value;
}

ExprStmt 则直接执行表达式，丢弃结果。之所以允许“一条只有表达式没有 print 的语句”，是为了以后扩展函数调用时，能写出 foo(); 这种命令式代码风格。

5. 性能疑虑与递归深度：跑得慢可接受，栈溢出不能接受

5.1 AST 解释器慢在哪：虚函数和指针追逐只是表象

很多人一听说解释器模式，第一反应是“这玩意儿跑起来是不是很慢”。确实，和直接编译成机器码相比，AST 解释器要慢一个数量级以上。但大部分自定义语言的使用频率并不高，规则表达式每次请求算一次，解析一次执行一次，完全不是性能瓶颈。真正慢的从来不是解释器本身，而是把热路径上的表达式反复解释。

慢的主要原因有三个：每个节点求值都是虚函数调用，每个操作都要在内存里跳来跳去找左右子树，而且每次求值都产生非常多的中间临时对象层级。MiniCalc 只有几十个节点时无伤大雅，但如果一个表达式有几万个节点，同时又在一段长循环里反复执行，那就要认真优化。

5.2 还能抢救一下：常量折叠与变量查找优化

一个很实用又不复杂的优化是常量折叠。在 parser 构建 BinaryNode 时，如果左右两个节点恰好都是 NumberNode，可以直接把它们的运算结果算出来，放进 NumberNode，让无效的中间树节点直接消失。这样既减少运行时求值次数，也让 AST dump 出来的结构更容易检查。

变量查找也可以针对高频场景做优化。如果规则里变量数量固定且很少，unordered_map 的开销可能比想象中大。一个轻量做法是先取样统计，再决定是否换用 vector 里线性查找。不过不要步子迈太大，除非你知道当前实现确实是热点，否则为这种查找优化反而容易破坏上下文设计的统一性。

5.3 遇到真正的高频场景，我建议升级成指令栈

如果某段表达式真的需要每秒执行上万次 AST 遍历，那我会调整设计：不直接反复遍历 AST，而是在第一次遍历时把树“编译”成一串简单的指令，比如常量入栈、变量入栈、加法、乘法、存储，然后执行一个基于 switch 的指令循环。这个方案本质上就是把 AST 树拍平成线性的字节码，运行时不再有虚函数调用，也不用一层层跳指针，性能能提升不少。

MiniCalc 暂时不需要走到这一步，但接口上最好预留余地。只要 AST 能支持一个独立的 pass 来生成指令，不破坏原有 eval，就不是伤筋动骨的重构。解释器模式的可迭代性就在于，你可以先拥有一个能正确工作的版本，再针对热点去升级后端，而不必一开始就写一个庞大虚拟机。

另一个被低估的问题是递归。AST 求值本质上是深度优先递归，如果业务方传了一个深度极大的表达式，比如几千层括号嵌套，或者构造出极其不平衡的加法链，求值器和 AST 析构函数都有可能把系统栈耗尽。MiniCalc 的 EvalContext 里可以加一个递归深度计数，当深度超过阈值直接抛异常。这样即便遇到对抗性输入，也只是报一条错误而不是让整个进程崩溃。如果你有时间，后续还可以研究迭代式析构和显式栈求值，但先做深度保护是性价比最高的方案。

6. 调试、测试和扩展：决定解释器能否交给别人维护的是这些

6.1 先写一个 AST dump，否则你会累死在日志里

解释器开发过程中，最麻烦的是中间结构不可见。Parser 如果解析错了，光看最终计算结果很难判断是词法错了、语法错了，还是求值逻辑错了。我每次写解释器都会优先补一个 dump 函数，把 AST 以缩进形式打印出来：

cpp复制void BinaryNode::dump(std::ostream& os, int depth) const {
    os << std::string(depth, ' ') << "Binary('" << op_ << "')\n";
    left_->dump(os, depth + 2);
    right_->dump(os, depth + 2);
}

对 print 3 + 4 * 2; 解析出来的 AST 做 dump，输出大致如下：

text复制Binary('+')
  Number(3)
  Binary('*')
    Number(4)
    Number(2)

这种输出比任何日志都直观。遇到解析不对的用例，先看 dump，马上能判断是优先级没对上还是括号处理漏了。AST dump 的代码虽然简单，但它是整个调试阶段的“眼睛”。

6.2 测试集要覆盖到解析错误和求值错误两类

解释器很容易出现“单个模块测着没问题，合起来就错”的情况，所以测试集必须同时覆盖语法规则、优先级、变量生命周期和运行时错误。MiniCalc 的测试用例可以从下面这些出发：

我踩过最典型的坑是“忘了测析构”。如果一次执行脚本很长、节点很多，递归的 unique_ptr 析构也可能把栈打爆。后来我把长度超过一万的加法链写进测试集，从那以后就再也不敢忽略析构路径。

6.3 后续加比较运算、if 语句和函数会动哪些地方

解释器模式的真正价值在扩展时才会体现出来。MiniCalc 如果只停留在加减乘除，只是玩具。但扩展路径是清晰的。加比较运算符时，文法先增加 comparison := additive (('==' | '!=' | '<' | '>') additive)?，然后在 AST 节点中增加 CompareNode，并把求值结果从 double 扩展成 Value 类型才能承载布尔值。这个改动会影响表达式节点的返回类型，所以如果一开始就判断出需要布尔值，最好让它返回一个 variant<double,bool>，而不是卡死在 double 上。

加 if 语句同样有套路。文法新增 ifStmt := 'if' '(' expression ')' statement ('else' statement)?，AST 增加 IfStmt 节点，里面持有条件表达式、then 分支和 else 分支。执行时先算条件，再决定执行哪个分支。函数调用则要涉及新的作用域链，EvalContext 不能再用一个单纯的 unordered_map 保存所有变量，而要引入作用域层级，在进入函数时让局部变量覆盖全局变量。

正因为这套扩展都发生在固定节点层面，解释器模式的健壮性就体现在：你不需要推翻字符串解析逻辑和 AST 容器设计，只需要在几个局部扩展点上增加新节点、新文法规则和新求值逻辑。这也是我后来很多项目宁可花一个周末自己写一个迷你 DSL，也不想把业务规则硬编码进 if-else 的原因。解释器模式真正带来的自由不是运行时的性能，而是让“语法变动”和“代码结构变动”彻底解耦。如果你以后也碰上一个需要频繁调整规则、又不想被字符串处理折磨的业务模块，不妨给自己留出这个周末，把一个最小可用的 AST 解释器搭起来；等你真的在这个骨架上慢慢加功能时，会慢慢体会到为什么这看似“最没用”的模式，反而能成为许多工程化代码库的底层支撑。