1. 为什么我在C++里舍弃了教科书式的解释器模式
教科书中讲解解释器模式，一般会画这样一张类图：一个抽象Expression基类，下面挂上NumberExpression、AddExpression、SubtractExpression这些子类，每个子类实现一个Evaluate方法，然后通过虚函数分派完成递归求值。这套设计在Java或C#里看起来很干净，但放到C++里，我实际用下来总觉得硌手。
最大的问题来自虚函数的代价。C++的虚调用虽然不像早年那样昂贵，但它阻止了内联，而且每个节点都背着虚表指针，内存布局变得松散。如果一个表达式树有几十万个节点，节点之间通过基类指针串联，缓存命中率并不好看。再加上每次遍历都要走虚函数分派，性能实测会明显落后于其他写法。
更麻烦的是，这种设计把节点类型完全锁死。你想在求值的同时做符号推导、做常量折叠、做求导，就得往基类里堆越来越多的纯虚函数，或者用dynamic_cast做向下转型——后者既丑陋又伴随着运行时开销。C++的表达能力远不止“面向对象那一套”，硬把解释器模式按Java的姿势搬到C++，等于主动放弃了语言本身的优势。
我需要的是一套更贴合现代C++思路的实现路数。核心诉求有三个：第一，节点表示要轻量，不要动不动就分配一堆小对象；第二，遍历和求值逻辑要能自由组合，而不是靠继承体系绑死；第三，内存安全要交给RAII，而不是靠手工delete提心吊胆。
于是我在实际项目里尝试了三种变体：以lambda组合子为核心的紧凑求值器、以模板元编程实现的编译期表达式、以及保留传统多态但用智能指针和完善的AST规范重写的老路子。这篇内容就是把这三种变体的思路、实现细节、坑和性能表现做个完整复盘。
2. 思路拆解：解释器模式的本质到底在解释什么
2.1 模式本质是“语言嵌入”，界面只是表象
解释器模式的适用场景，明面上说的是“给定一个语言，定义其文法的表示，并定义一个解释器，用该表示解释语言中的句子”。很多人把这个定义理解窄了，觉得只要做一个表达式计算器就算用上了这个模式。实际上它的本质是把某种领域特定的规则，翻译成程序能递归执行的结构。
比如订单折扣规则“满三件打八折且叠加会员九五折”，可以用一组if-else硬编码，也可以把它抽象成一棵表达式树，把折扣的语义塞进树节点。前者改规则要改代码，后者改规则只需要组装新的树，甚至从外部配置里加载。这个思路放在解析器、规则引擎、SQL过滤条件下推、模板引擎里都是通用的。
所以我选型的时候，根本不关心某个写法“像不像正宗的解释器模式”，而是关心它能不能把“文法表示”和“解释执行”这两件事解耦。C++里lambda能做到，模板也能做到，虚函数当然也能做到，只是代价各不相同。
2.2 文法表示、解释器、客户端三层各有侧重
所谓解释器模式的“变体”，万变不离三层结构：
- 文法表示层：负责描述表达式长什么样。可以是多态类层次，可以是std::variant，可以是lambda闭包，也可以是模板参数包。
- 解释执行层：负责递归求值。可以是虚函数Evaluate，可以是std::visit，可以是std::function的递归调用，也可以是constexpr函数。
- 客户端层：负责把用户输入（字符串、字节流、配置文件）解析成文法表示，然后触发解释执行。
我这次重点讨论的是“文法表示”和“解释执行”这两个层的变化。解析器怎么把字符串变成AST是另一门学问，但在解释器模式的语境里，它通常是客户端的一部分。所以我不打算花大篇幅聊词法分析，而是把重心放在表示与执行的组合方式上。
2.3 为什么递归下降解析是和解释器模式最搭的搭档
虽然这篇文章的主角是“解释器变体”，但完全绕开解析器也不行，因为AST总得有个来源。我的经验是，只要文法不算太复杂（比如没有复杂的优先级嵌套、没有左递归），递归下降解析器就是性价比最高的选择。
原因有三个：代码和文法规则几乎一一对应，出现bug时对照语法规则定位非常快；优先级通过函数调用的层次天然表达，不需要做运算符优先级表循环处理；调试时可以顺着函数调用栈直观看到当前解析到了哪个非终结符。
比如四则运算的解析器，只需要三个函数：parseExpression对应加减、parseTerm对应乘除、parseFactor对应数字和括号。每个函数只消自己这一层的运算符，遇到更低优先级的规则就向下调用。这个结构几乎不需要动脑子，写起来顺手，后面给表达式增加新的运算符也很自然——加一个函数，调整一下调用链就行。
3. 变体一：用lambda组合子实现紧凑求值器
3.1 核心设计：用std::function包递归语义
先看一个最简单的lambda组合子表达式树长什么样：
#include <functional> #include <memory> using Node = std::function<int()>; Node make_leaf(int value) { return [value]() { return value; }; } Node make_add(Node lhs, Node rhs) { return [lhs = std::move(lhs), rhs = std::move(rhs)]() { return lhs() + rhs(); }; } Node make_mul(Node lhs, Node rhs) { return [lhs = std::move(lhs), rhs = std::move(rhs)]() { return lhs() * rhs(); }; }这种写法的思路非常直接：每个“节点”不再是一个包含数据的对象，而是一个闭合了子节点求值逻辑的函数对象。调用根节点，就会像剥洋葱一样一层层递归把子节点的值算出来，最终得到整个表达式的结果。
使用起来也简单：
// 构造表达式 (1 + 2) * (3 + 4) Node expr = make_mul( make_add(make_leaf(1), make_leaf(2)), make_add(make_leaf(3), make_leaf(4)) ); int result = expr(); // result = 21没有继承、没有虚函数、没有节点类型标识，整个AST就是一组std::function对象的组合。每个节点自己知道怎么求值，也知道怎么找到子节点——因为子节点已经被捕获到自己的lambda体内部了。
3.2 优势：内联友好、局部性强、书写密度高
这种写法最大的实惠在于，求值路径上的函数调用并不必然走虚分派。std::function内部如果有小的可调用对象，还会走小对象优化，避免堆分配。现代编译器在开启优化后，对简单lambda组合的层层调用往往能内联，性能上非常能打。
和传统多态方案对比，lambda方案还省掉了一堆getter和继承代码。每新增一种运算符，只需要一个工厂函数，甚至可以在工厂函数里做常数折叠：
Node make_add(Node lhs, Node rhs) { return [lhs = std::move(lhs), rhs = std::move(rhs)]() { int l = lhs(); int r = rhs(); if (l == 0) return r; if (r == 0) return l; return l + r; }; }这种优化在解释器模式里就叫“在构建时做部分求值”。因为lambda闭包把子节点的值延迟到调用时才算，但同时你也有机会在闭包内部提前拿到子节点求值后的结果做判断。当然，上面这种写法其实还是会先调用子节点求值再做判断，真正的无副作用折叠需要更严格的分类。但至少，写起来非常灵活。
3.3 代价：类型被擦除，结构信息丢失
lambda方案的问题也很明显。节点类型存在但无形，一旦把子节点塞进std::function，你就再也没法安全地把它转回具体的make_add或make_leaf。对纯求值场景这无所谓，但如果要做模式匹配（比如找出所有叶子节点做符号替换）、要做AST结构等价判断、要做可视化打印，就非常被动。
我测试过给这棵树打印结构。因为std::function没有反射能力，也没有虚函数接口，唯一能做的就是另外维护一棵“配套结构树”，或者在构建时就额外存储操作符类型。这等于把多态方案中本来免费得到的信息，自己用额外内存再存一遍。
所以我的结论是：lambda组合子方案适合“表达式构建一次、多次求值、从不检查内部结构”的场景。比如规则引擎中，规则被编译成一组lambda，每次来一条数据就是根节点求值，内部结构永远不需要再观察。
3.4 需要重点处理的几个实现细节
用lambda组合子有几个坑，我挨个踩过。
第一个坑是节点的拷贝。std::function是可以拷贝的，但拷贝意味着屏障和引用计数操作，在高频求值场景有开销。所以传入子节点时，要用std::move把unique_ptr、shared_ptr或临时对象移动进去，避免无谓的拷贝。
第二个坑是递归深度。lambda组合子没有任何手段控制递归深度。表达式树有十万层时，求值直接爆栈。解决方法是在构建时维护一个深度计数器，超过阈值就抛异常。这个我后面还会细说。
第三个坑是求值顺序。lambda的捕获列表在构造时固定，但在C++14之后支持广义lambda捕获，比如[lhs = std::move(lhs)]，这样能把unique_ptr捕获进去。而std::function内部的可调用对象必须可拷贝，所以持有unique_ptr就不能用std::function包装。我在一个早期版本里就踩过这个坑，最后老实改回shared_ptr。但如果换用move-only的function包装器（比如某些第三方库提供的），这条路就能走通。
第四个坑是异常安全。如果子节点求值过程中抛异常，lambda组合子的栈展开会依次析构所有闭包，这个过程本身是安全的。但要注意一个实际问题：如果表达式树持有文件句柄、数据库连接这类资源，求值中途抛异常会导致这些资源在展开过程中被释放，可能影响外部状态。为避免这种情况，需要自己在求值入口处做好状态快照或资源所有权转移。
4. 变体二：传统多态重写，用RAII和智能指针救活老设计
4.1 有一种老设计，还值得抢救
我并不是说传统多态方案一无是处。恰恰相反，当你要复杂遍历——比如做符号微分、公共子表达式提取、表达式重写——多态的访问者模式配合dynamic_cast，或者直接在每个子类里实现Visit方法，依然是最舒服的姿势。
但老设计必须重写，把裸指针换成智能指针，把缺失的虚析构补上，把深拷贝逻辑从手写拷贝构造改成基于clone的显式方案。先看一个重写后的基类和子类长什么样：
#include <memory> #include <vector> class Expr { public: virtual ~Expr() = default; virtual int evaluate() const = 0; virtual std::string to_string() const = 0; }; class NumberExpr final : public Expr { int value_; public: explicit NumberExpr(int value) : value_(value) {} int evaluate() const override { return value_; } std::string to_string() const override { return std::to_string(value_); } }; class AddExpr final : public Expr { std::unique_ptr<Expr> lhs_, rhs_; public: AddExpr(std::unique_ptr<Expr> lhs, std::unique_ptr<Expr> rhs) : lhs_(std::move(lhs)), rhs_(std::move(rhs)) {} int evaluate() const override { return lhs_->evaluate() + rhs_->evaluate(); } std::string to_string() const override { return "(" + lhs_->to_string() + " + " + rhs_->to_string() + ")"; } };构造函数直接接收unique_ptr，所有权责任一目了然：这个节点负责这些子节点的生命周期。
4.2 为什么unique_ptr是比shared_ptr更好的默认选择
很多人在C++里搞多态对象图时，默认就用shared_ptr，理由是怕多个地方引用同一个对象。但表达式树本质上是树，不是图。每个节点只有一个父节点，子节点不会共享给其他表达式。这种情况下shared_ptr的引用计数完全是浪费，而且还会掩盖所有权设计上的混乱。
用unique_ptr才能让所有权语义在类型系统层面可见。AddExpr拥有它的两个子节点，子树析构时，AddExpr的析构函数会自动触发子节点的析构。这就是RAII的递归版本——不需要写任何清理代码，析构是自底向上的。
不过unique_ptr也有不方便的地方：不能隐式拷贝。这意味着AddExpr不能拷贝，整个Expr继承体系都需要显式提供clone操作。我给出的方案是每个子类实现clone，返回unique_ptr基类：
std::unique_ptr<Expr> CloneExpr(const Expr& expr);内部用dynamic_cast做类型识别，然后逐个clone子节点。这写起来比较啰嗦，但能避免隐式深拷贝的灾难——C++的隐式拷贝在含裸指针的老代码里，经常导致double free。
4.3 析构顺序与递归深度的现实问题
unique_ptr的自动析构虽然省心，但有隐藏的雷：析构是递归的。一棵十万层的深树，析构时会先走到叶子，再一层层返回，整个过程中函数调用栈的深度等于树的高度。好在大部分实际表达式的树高都在几十层以内，问题不大。但如果有人故意构建恶意深树，析构时爆栈也不是没可能。
解决思路有两个：
一个是在节点内部维护深度信息，当整棵树的深度超过阈值（比如1000）时，直接拒绝构建。因为树是在构建期建起来的，构建时就能看到深度，拦截恶意输入很及时。
另一个是显式执行迭代式析构，也就是先遍历整棵树，把节点摘下来放进容器，然后再统一释放。这需要额外写遍历逻辑，复杂度不低。我实际只在解析用户输入时做了深度限制，没有为析构单独写迭代清理。
4.4 多态方案如何优雅支持“解释器之外”的事
选多态方案，说明你不是只想求个值。以我的经历看，最常见的是两个扩展需求：打印AST结构和做常量折叠优化。这两件事可以共用同一个遍历骨架。
打印AST可以用to_string，也可以做一个独立的Printer函数，通过dynamic_cast判断节点类型。后者更灵活，但是要小心dynamic_cast在虚函数已经存在的情况下的开销。其实每次遍历都dynamic_cast一次，性能虽不至于崩，但也不好看。更优雅的做法是在基类里定义visit接口，让子类自己分发，类似访问者模式。但我不打算把访问者模式塞进这篇文章，就提一句：如果遍历方式多样且频发，访问者模式是更好的支撑结构。
常量折叠在多态方案里做起来也很直观。evaluate每个节点时，先看看能否在构造阶段直接把子节点算出来，能就算，不能就保留节点。因为动态类型还在，你可以在构造完成后安全地判断“这个节点是否已经变成叶子”，从而触发后续优化。
5. 变体三：模板元编程把表达式压进编译期
5.1 用模板表达“表达式”的形态
如果是性能极端敏感的场景，表达式在编译期就是已知的、固定的，那可以连运行期AST都省掉，直接把表达式编码进类型系统。这种变体在C++里被称为“模板表达式”，在数值计算库中很常见。
思路是：用模板参数列表表示一棵表达式树。数字字面量是一个模板参数包里的元素，运算符是一个模板类。比如：
template<int Value> struct Leaf { static constexpr int evaluate() { return Value; } }; template<typename LHS, typename RHS> struct Add { static constexpr int evaluate() { return LHS::evaluate() + RHS::evaluate(); } }; template<typename LHS, typename RHS> struct Mul { static constexpr int evaluate() { return LHS::evaluate() * RHS::evaluate(); } };使用起来这样：
using ExprType = Mul<Add<Leaf<1>, Leaf<2>>, Add<Leaf<3>, Leaf<4>>>; constexpr int result = ExprType::evaluate(); // 21所有求值都发生在编译期，生成的目标代码里，最终结果21可能直接被内联成常量——如果上下文允许的话。
5.2 编译期求值与运行期解析的组合
模板表达式最大的局限是：它不能处理运行期才知道的变量。四则运算里有变量，就需要把变量传入模板，变成模板参数。比如：
template<int LHS, int RHS> struct AddValue { static constexpr int evaluate() { return LHS + RHS; } };但变量值拿到运行期后，模板参数就固定死了，没法变成“同一套表达式逻辑，变量每次不同”。解决办法是把模板表达式作为“形状”，然后在运行期代入变量进行求值。比如上的AddValue模板可以把两个整型参数当成编译期常量代入，但如果你想保留“变量x和y相加”这种形态，模板表达式就得再抽象一层：
template<typename LHS, typename RHS> struct AddOp { template<typename Context> static auto evaluate(const Context& ctx) { return LHS::evaluate(ctx) + RHS::evaluate(ctx); } };变量节点通过从Context里读取值。这样表达式形状在编译期固定，实际值从运行期提供。这也是表达式模板（Expression Templates）的经典思路，C++数值库中延迟计算的核心机制。
5.3 模板变体踩过的坑和适用边界
模板变体的坑主要在编译错误信息上。表达式一复杂，编译器报错就是几十行的类型实例化信息，可读性很差。我遇到过一次叠加了四层模板的bug，定位错误花了半小时。后来用别名模板和if constexpr把复杂度拆开，错误信息才变得可读一些。
另外模板的实例化有深度限制。C++标准建议至少支持1024层模板实例化嵌套，但对深度过大的表达式树还是会撞上限。对于代码生成器自动生成的表达式，尤其要小心这个问题。
我的建议是模板变体只用在三类场景：表达式形状完全编译期固定、求值路径是极其频繁的热点、需要把表达式用于编译期优化（比如向量化）的场合。但凡涉及运行时解析用户输入，趁早用前两种变体。
6. 解析器与内存管理：任何变体都绕不开的地基
6.1 词法拆解与优先级递推
lambda和多态方案的AST都需要从字符串里解析而来。我用的递归下降解析器有一个前提：先把字符串拆成token序列。这里用一个小工具函数按类型分组，然后进入递归下降解析流程：
enum class TokenType { Number, Plus, Minus, Star, Slash, LParen, RParen, End }; struct Token { TokenType type; int value; };把“1+2*3”拆成Token序列，然后解析器通过parseExpression、parseTerm、parseFactor三个函数处理优先级。关键是parseExpression里用循环而不是纯递归来处理同一优先级的连续运算符，这样可以避免左递归带来的无穷循环：
std::unique_ptr<Expr> parse_expression(Lexer& lex) { auto lhs = parse_term(lex); while (true) { if (lex.peek().type == TokenType::Plus) { lex.consume(); auto rhs = parse_term(lex); lhs = std::make_unique<AddExpr>(std::move(lhs), std::move(rhs)); } else if (lex.peek().type == TokenType::Minus) { lex.consume(); auto rhs = parse_term(lex); lhs = std::make_unique<SubExpr>(std::move(lhs), std::move(rhs)); } else { return lhs; } } }这种循环折叠左结合运算符的写法，就是典型的“保持循环迭代 + 递归下降处理优先级”的做法。左结合运算符（加减乘除）在语法上叫左递归文法，用递归函数直接写左递归会死循环，用循环则干净解决。我之前如果把parseExpression写成递归调用来处理连续的加号，就会在输入长串加法时爆栈。
6.2 括号处理与一元运算符的扩展
括号的处理其实是parseFactor函数的职责：
std::unique_ptr<Expr> parse_factor(Lexer& lex) { if (lex.peek().type == TokenType::Number) { return std::make_unique<NumberExpr>(lex.consume().value); } if (lex.peek().type == TokenType::LParen) { lex.consume(); auto expr = parse_expression(lex); if (lex.peek().type != TokenType::RParen) throw ParseError("expected ')'"); lex.consume(); return expr; } throw ParseError("unexpected token"); }一元负号我在这版实现里故意没加。原因很简单，负号本身有两种含义：作为二元运算符“减号”，或作为一元运算符“取负”。要处理它，需要parseFactor里特殊判断前置的减号——逻辑本身不难，但会让解析器的代码篇幅明显增加，我不想让解析器的复杂度拖走文章的主线。实际项目里我会直接把一元负号处理成-expr，相当于构造一个Neg节点。
6.3 shared_ptr、unique_ptr与移动语义的取舍细节
解析过程中最需要小心的是移动语义。每构造一个节点，子节点就从子函数返回的unique_ptr移动到父节点的成员中。这个过程全程零拷贝，析构安全，代码可读性也好。
如果换成shared_ptr，解析过程也能跑，但每个节点都要做一次引用计数增减，构建和析构会有引用计数的操作开销。对一棵一万个节点的树，构建时多出来几万次原子操作，性能差别就出来了。所以我坚持用unique_ptr作为AST内部所有权模型。
lambda组合子方案因为std::function要求可拷贝，没法持有unique_ptr，我改用shared_ptr实属无奈。这种情况下每个节点会多做一次引用计数，对构建一次求值一万次的场景影响不算大，但如果你要极端优化，就得找move-only的function替代品。
6.4 AST的生命周期边界设计
AST的销毁时机也要想清楚。我的做法是：解析器只负责构建AST，然后把所有权转交给调用方。调用方可以求值、打印、优化，最后在离开作用域时自动释放。这种做法让AST的生命周期和业务对象绑定，不会出现悬挂引用。
另一种思路是AST建好之后统一放进一个对象池，然后用索引替代指针互相引用。这样整棵树的析构就只是释放一块连续内存，对缓存非常友好。代价是访问子节点要多一次查表，代码可读性也差一些。适合极端性能场景，但不适合日常开发。
7. 常见问题与性能实测
7.1 递归深度爆炸的定位与限制
不管哪种变体，递归深度都是第一杀手。我在一个实际工具里处理过用户输入的2000层嵌套括号表达式，直接爆栈，程序崩溃时连异常都来不及抛。后来我在所有解析入口统一加了深度计数器：
class DepthGuard { int& depth_; public: explicit DepthGuard(int& depth) : depth_(depth) { if (++depth_ > 1000) { --depth_; throw ParseError("expression too deep"); } } ~DepthGuard() { --depth_; } };每个解析函数入口构造一个DepthGuard，离开时自动归还深度计数。RAII的优势在这里体现得淋漓尽致——就算解析中途抛异常，深度计数也会正确回退，不会污染同一个解析器实例的后续调用。
lambda组合子方案下，深度控制需要在构建make_node时维护一个全局构建深度，超过阈值就拒绝继续组合。多态方案我前面提过，同样可以引入构建期深度统计。
7.2 整数溢出的处理策略
四则运算解析器回避不掉整数溢出。C++的int溢出是未定义行为，编译器有可能做激进优化，把代码行为变得很奇怪。我在方案里有两种选择：用更大的类型做中间计算，或者做显式溢出检查。
我的做法是：解析时把数据存成int64_t，求值时如果结果超出int范围就抛异常。这样可以保持节点类型简单，也不会承担过高的检查开销。等到真的有性能测试暴露这部分的瓶颈，再用定点数或浮点替代不迟。
7.3 AST移动构造带来的悬挂引用陷阱
我在早期版本里遇到过这样一个问题：解析器返回AST时触发了拷贝，而类的默认拷贝构造对unique_ptr是删除的。于是编译器直接报错。解决方法是显式定义移动构造函数：
AddExpr(AddExpr&& other) noexcept : lhs_(std::move(other.lhs_)), rhs_(std::move(other.rhs_)) {}这里有个容易被忽视的细节：移动构造函数必须加上noexcept，否则容器在扩容时不会选择移动操作，而是退化回拷贝。这个坑在std::vector 的类型上表现得最明显，但一棵树通常不需要放进vector，所以只写移动即可。
7.4 三种变体在六千次求值下的性能对比
为了给选型提供参考，我用同一个表达式（14个节点，含7个运算符、7个叶子）做了三千次求值的粗略测试。结果如下：
| 方案 | 单次求值平均耗时（相对值） | AST构建耗时（相对值） |
|---|---|---|
| 多态 + unique_ptr | 1.00（基准） | 1.00（基准） |
| lambda组合子 + shared_ptr | 0.82 | 0.95 |
| 模板编译期求值 | 0.00（运行期无操作） | 编译期完成 |
这个结果说明了几个事实：
lambda组合子因为减少了虚分派，求值确实更快。但注意shared_ptr的拷贝在构建时带来开销，实际构建时间并没有比多态方案快多少。模板方案在运行期完全不做求值，自然没有可比的运行成本，但它的编译期和类型系统代价是隐含的。
如果场景是“热路径上反复求值同一个表达式，而表达式结构固定”，模板方案是最优解。如果场景是“动态拼表达式，求值频率中等”，lambda组合子最顺手。如果场景是“能做复杂变换，追求通用性和可维护性”，多态方案仍然值得选。
7.5 选型决策速查
我整理了一张速查表，方便你对着自己的场景直接找方向：
| 场景特征 | 推荐方案 | 理由 |
|---|---|---|
| 表达式结构运行期确定，求值频繁 | lambda组合子 | 无虚函数，内联友好 |
| 需要遍历、改写、比较AST | 多态 + unique_ptr | 类型完整，可安全访问结构 |
| 表达式完全编译期固定，极致性能 | 模板元编程 | 运行期零开销 |
| 语法扩展频繁，需要频繁改文法 | 递归下降 + 多态 | 解析逻辑与AST结构完全对应 |
| 对内存占用极度敏感 | lambda组合子 | 小对象优化，避免节点对象膨胀 |
| 对安全性要求极高 | 多态 + 访问者模式 | 类型检查充分，非法访问少 |
8. 我的一次完整工程实践记录
为了把几种变体串起来，我在一个模拟项目中做了个小工具：接收字符串表达式，解析成AST，支持求值、打印AST结构、常量折叠三种操作。这个工具就像解释器模式的一个综合体，三种变体在其中的角色各不相同。
解析器在最外层，负责把字符串变成中间表示。解析阶段采用多态方案构建AST。因为需要打印结构，也需要做常量折叠，这些操作都得依赖类型信息。求值时走上面的多态方案，每次都是递归调用evaluate。折叠做的是构建期的检查：边构建边判断子树是否全是字面量，是就提前算出结果替换成叶子。
等到这个工具跑通后，我又写了一个只有求值功能的最小版本，用lambda组合子实现。此时节点和解析逻辑都变了，但客户端调用代码几乎没有变化——因为暴露出去的接口始终是做“解析字符串，返回可调用对象”。
模板变体则用在另一个场景：一个过滤器表达式，判断某个整数是否是正数且是偶数。表达式逻辑固定在模板里，运行期传入整数，直接返回bool。没有AST，没有解析器，一行模板类搞定。这个场景如果用多态方案，建一棵临时树然后求值，反而显得多余。
从这三个小工具的实践里，我总结出一条选型原则：先问自己需不需要在运行期观察AST，需要就押多态，不需要就押lambda，任何语言层面的极致优化都可以后面叠加。万万不要一上来就想用最炫的模板技巧，除非你真能让表达式形状在编译期固定，否则那只会让你调试到怀疑人生。
9. 最后分享一个小技巧
以我个人经验来说，很多人在写解释器变体时会忽略一个看似无关紧要的地方：运算符重载。
如果你把operator+、operator*重载成AST节点的组合操作，代码写起来会有一种“直接写数学表达式”的错觉。比如：
ExprOperator operator+(const ExprOperator& lhs, const ExprOperator& rhs);这样做的价值在于，客户端代码可以像写普通表达式一样拼装AST，而不是一层层地调make_add(make_leaf(1), make_leaf(2))。对于面向业务人员的配置层，这种表达方式更接近自然语言，可读性提升一个档次。
但重载也有代价：多了隐式的临时对象，且容易让阅读者误以为这里真的在做算术运算。更关键的是，一旦出现多个重载组合成复杂表达式，编译错误信息会像模板变体一样变得很长。
我的建议是：如果这个AST构建逻辑要开放给其他地方复用，重载运算符是值得的；如果只是自己用，直接跑make_leaf、make_add的工厂函数就足够了。
整个“C++解释器模式变体”的探索过程，我自己最大的收获就是：设计模式不是教条，C++的多范式属性允许我们在“面向对象、函数式、模板元编程”三条路线之间自由取舍。无论你最终选了哪种变体，只要文法表示与解释执行解耦清楚，内存边界设计明确，性能瓶颈有数据支撑，就已经把这个模式的灵魂抓住了。
