眠子子子如果你在C++项目里写过小规则引擎、做过公式计算，八成会翻到解释器模式。我第一次在真实项目里用它，是在一个服务端配置模块里塞一条表达式：region == "CN" && pv < 3，当时参考书里写得很清楚：抽象出Expression基类，常量、变量、二元运算分别继承它，最后外层调用eval()遍历树求值。第一版功能确实正常。但后面需求一变，比如加"支持函数调用"、"把表达式渲染成调试文本"，我会发现到处都是零散改动。后来我重写时没有照搬教科书里的类结构，而是组合使用了现代C++几种惯用法——std::variant、std::visit、操作符重载、甚至编译期模板元编程。不同写法其实都是解释器模式的变体，它们在语法稳定度、操作扩展方向、性能上有完全不同的取舍。这篇文章就把我实践过的几条路线摊开对比，希望给同样在C++里做表达式求值、规则解析的朋友一些参考。
1. 解释器模式解决的核心问题：从计算式到执行树的映射
1.1 “语言”在代码里到底是什么
先说个朴素认识。解释器模式不是用来解析JSON，也不是用来把一串字符串切成token。它解决的是：当你已经有了一棵合法表达式树时，如何给这棵树定义行为。所谓“语言”，在模式语境里可以很小，小到一个只支持加减乘除的计算器；也可以很大，大到SQL的WHERE条件子集。
通常你会先把输入文本词法分析、语法分析，生成一个抽象语法树。然后问题就变成：对这棵树的每种节点，比如Number、Variable、BinaryOp，提供统一的执行入口。教科书会告诉你，定义抽象基类Expression，让每个具体节点类去实现evaluate。调用者拿到顶层表达式后，只需要调用一次eval，剩下的事由递归完成。
这其实是对“解释”的建模：把语法翻译成可执行操作。对C++来说，解释器模式最直观的形态是“对象树+虚函数+递归遍历”，但并不能说这个形态在真实工程里就是最好用的，尤其当你需要频繁扩展语法，或者频繁扩展围绕这棵树的新操作时。
1.2 一个简单的表达式文法示例
为了后面几种变体能放在同一个参照系里，我约定一个极简表达式语言：
code复制expr := term (('+' | '-') term)*
term := factor (('*' | '/') factor)*
factor := NUMBER | '(' expr ')' | IDENT
支持的东西包括：数字常量、变量、四则运算、括号。变量在求值的时候从一个VarMap里取。如果要做变量赋值、函数调用，都是一样的扩展套路，但没必要在第一版就上。
语法树本质上是一种递归结构。比如1 + 2 * 3，最顶上是Add节点，左边是常量1，右边是Mul节点，而Mul的左右是两个常量。所谓“解释”，就是从树的根节点开始往下，按节点类型决定下一步动作。
1.3 把这个场景投影到生活里
你可以把每个表达式节点想象成积木盒。常量节点是一个只有一个数字的盒子，变量节点是一个写着变量名的盒子，二元运算节点是有左右两个槽位、且槽位里还能塞积木盒的盒子。解释器要做的，就是把最外层盒子打开，根据盒子上贴的标签决定怎么处理里面的东西，如果里面还有子盒子就递归拆。
这套思路本身完全没有问题，我在很多C++项目里还见过类似的过滤器解析。问题往往出在实现层：我们到底用多少类表示节点，用什么样的多态机制带起递归，树的所有权怎么管理，这些细节决定了这套模式在项目里是神兵利器还是维护负担。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 教科书式写法很好懂，但真实项目里不好改：我拿表达式引擎验证的三点教训
2.1 经典继承结构长什么样
先还原一下最正统的C++版本。假设表达式最终返回double，变量从外部环境里取，节点会持有子节点指针。教科书通常这样设计：
cpp复制class Expression {
public:
virtual ~Expression() = default;
virtual double eval(const VarMap &vars) const = 0;
};
class NumberExpr : public Expression {
double value_;
public:
explicit NumberExpr(double value) : value_(value) {}
double eval(const VarMap &) const override { return value_; }
};
class VariableExpr : public Expression {
std::string name_;
public:
explicit VariableExpr(std::string name) : name_(std::move(name)) {}
double eval(const VarMap &vars) const override {
return vars.at(name_);
}
};
class BinaryExpr : public Expression {
char op_;
std::shared_ptr<Expression> left_, right_;
public:
BinaryExpr(char op,
std::shared_ptr<Expression> left,
std::shared_ptr<Expression> right)
: op_(op), left_(std::move(left)), right_(std::move(right)) {}
double eval(const VarMap &vars) const override {
double l = left_->eval(vars);
double r = right_->eval(vars);
switch (op_) {
case '+': return l + r;
case '-': return l - r;
case '*': return l * r;
case '/': return l / r;
default: throw std::runtime_error("bad op");
}
}
};
代码本身可读性很好，也很容易讲给新成员听：类型层次和语法结构一一对应。新加一种合法语法，比如一元负号UnaryMinusExpr，就新建一个类，重写eval。新加一种执行方式，比如想输出RPN格式或生成dot图，就得去改Expression接口，或是在每个节点类里加成员函数。
2.2 教训一：类数量会随着文法扩展“非线性”变多
一个只支持四则运算和变量的语法，用类表达倒还好，三五个类就搞定。可一旦想支持取模、幂运算、逻辑与或、比较、函数调用、三元表达式，节点类会快速膨胀。每一个二元运算都要控制自己的左右子树，而且遇到有同学把每个运算符单独做一个类，类文件数量就肉眼可见起飞。
真实项目里不会有人愿意为“加一个比较运算符”新建一个文件。于是大家开始偷懒：把运算符种类收进BinaryExpr内部，用enum区分。这其实已经偏离了教科书，因为解释器模式的“一语法一节点”假设变得没那么纯粹，反而更像命令解析器。
2.3 教训二：操作方向的扩展需要在所有节点类里“打补丁”
往语法树里加操作是最常见的演进诉求。今天要eval，明天要toText，后天要把表达式序列化成配置再反序列化回来，大后天还要做类型检查。如果每个节点类都加一个成员函数，等于每次新增操作都把这段逻辑切碎撒在代码库里。
对策是引入Visitor模式：单独定义ExpressionVisitor，每种节点实现一个accept(visitor)，这样新操作集中写到新的Visitor类里。问题又来了，你要维护两套互相咬合的类层级，C++不像某些带模式匹配的语言那么自然。解释器模式本来是想简化代码，结果为了绕过“虚函数难扩展”又造了一套复杂度，这不划算。
2.4 教训三：树的所有权和生命周期很容易失控
用shared_ptr满天飞，虽然内存安全了，但树的结构变模糊。很多节点被多个父节点共享时，稍不注意就出现循环引用或意外改到其他子树。想深拷贝时也麻烦，因为每个类都要写拷贝构造函数，而C++默认拷贝会让多个节点共享同一批子节点。对这些节点操作时，往往只读还好，一旦有节点持有可变状态、需要在求值过程中写入暂存值，共享语义就会引入隐蔽bug。
所以在C++里落地解释器模式，首先要回答的问题不是“虚函数好不好”，而是“我的节点能不能用更扁平的表示”。这让我逐步走向下面几种变体。
3. 变体一：std::variant + std::visit 压平节点继承层
3.1 为什么我会想到用 variant 表示语法树
C++17引入std::variant之后，很多继承层次都能被“类型安全union”替代。语法树天然的封闭特点正好契合variant：一个表达式节点，要么是数字，要么是变量，要么是二元运算，不太需要天马行空地增加未知节点。只要这个集合在编译期确定，我们就能把“节点类型”拍平成一个值。
这种做法在语法设计层面相当于提前声明：我们接受的语法节点类型是有限的、明确的。既然有限，就不需要委托给继承和多态，直接让编译器和模式匹配来帮忙分发。
3.2 递归的 variant 表达式结构
用variant表达递归树时，难点在于怎么存放子节点。最简单方式是让二元运算持有两个std::unique_ptr<Expr>，而Expr内部再包一个variant。
cpp复制class Expr;
enum class Op {
Add,
Sub,
Mul,
Div
};
struct NumberExpr {
double value;
};
struct VariableExpr {
std::string name;
};
struct BinaryExpr {
Op op;
std::unique_ptr<Expr> lhs;
std::unique_ptr<Expr> rhs;
};
// 节点集合被显式写进variant，这就是“封闭类型集合”
using ExprData = std::variant<NumberExpr, VariableExpr, BinaryExpr>;
class Expr {
public:
ExprData data_;
};
这里有个细节值得注意：BinaryExpr里存的是std::unique_ptr<Expr>，不是Expr本身，因为Expr作为最外层包装，内部如果又直接持有Expr就是无限递归。用unique_ptr可以打破递归。严格地说，C++标准要求使用递归类型时尽量不要让智能指针析构发生在类型不完整阶段，这个结构在绝大多数主流编译器下只要常规使用都没问题。如果遇到编译期关于Expr析构的报错，可以在类外显式定义析构函数：
cpp复制class Expr {
public:
ExprData data_;
~Expr();
};
Expr::~Expr() = default;
这个动作会推迟若干隐式析构的实例化点，我实际处理时靠它解决过一次比较苛刻的跨模块编译问题。
3.3 用 std::visit 完成解释
求值逻辑可以写成一个独立函数，通过std::visit分派到每个具体节点。C++17里常用一个小工具overloaded。
cpp复制template <typename... Ts>
struct overloaded : Ts... {
using Ts::operator()...;
};
template <typename... Ts>
overloaded(Ts...) -> overloaded<Ts...>;
double eval(const Expr &expr, const VarMap &vars) {
return std::visit(overloaded{
[](const NumberExpr &n) {
return n.value;
},
[&](const VariableExpr &v) {
return vars.at(v.name);
},
[&](const BinaryExpr &b) {
double left_val = eval(*b.lhs, vars);
double right_val = eval(*b.rhs, vars);
switch (b.op) {
case Op::Add: return left_val + right_val;
case Op::Sub: return left_val - right_val;
case Op::Mul: return left_val * right_val;
case Op::Div: return left_val / right_val;
}
throw std::runtime_error("unknown op");
}
}, expr.data_);
}
这已经和经典写法有了本质差别。没有Expression基类，没有virtual，没有子类去覆写eval。所有解释操作集中在eval里，而std::visit负责把当前存储的具体类型路由到对应lambda。如果某天想支持新操作，比如输出AST缩进文本，只需要新增一个独立函数，不需要改动节点任何类。这正是很多人说“现代C++里访问者模式比继承更适合做这种封闭多态”的原因。
3.4 这个变体的收益与代价
收益很明显：
- 节点类型集中在variant里，代码自文档化，打开头文件就知道语法有哪些节点。
- 新操作扩展成本低，集中在函数里。
- 小节点（如数字常量）直接按值存在variant内部，很多时候能避免堆分配，缓存友好性比经典写法好。
代价也要说清楚：如果未来语法节点经常增加，就是另一种麻烦。每次新增一种节点都要改variant类型，且所有已经写好的visit函数都必须跟着调整，编译器会强制你处理新case。这其实是把“漏加新节点”从运行时问题提到了编译期，对做解释器这种需求不算坏事，但如果你真在做一个允许用户插件注册新语法结构的框架，variant就不是好选择。
3.5 用示例来理解“操作分区”
假设我要在原有eval之外加一个collectVariables，用于统计表达式里出现哪些变量。在经典继承里，要改接口和所有类；在variant版本里，加一个函数就行：
cpp复制void collectVariables(const Expr &expr, std::set<std::string> &out) {
std::visit(overloaded{
[](const NumberExpr &) {},
[&](const VariableExpr &v) {
out.insert(v.name);
},
[&](const BinaryExpr &b) {
collectVariables(*b.lhs, out);
collectVariables(*b.rhs, out);
}
}, expr.data_);
}
这类函数可以自由放在eval旁边，甚至放进不同文件里的工具命名空间。语法节点类本身不需要知道有多少种操作，这减少了大量“打补丁”代码。
4. 变体二：操作符重载把解释器“嵌进”表达式构造过程
4.1 不是所有规则都要从文本开始解析
很多业务场景里，表达式并不是从外部配置文件读进来的，而是上层业务代码需要按条件动态组合。比如风控规则，某个运营策略希望表达“当用户等级大于3且VIP有效时打折”。与其让业务代码拼一个字符串再交给解析器，不如直接在C++里用可读性强的组合方式构造规则。
这种让调用方直接用C++运算符“自然拼接”出的表达式，可以看作解释器模式的另一种变体：不再预先构造一棵中立的AST，而是通过操作符重载让表达式在书写时就把求值函数闭包组合好。用“即时组合、延迟求值”的眼光看，表达式对象本身就是一个微型解释器。
4.2 用闭包作为节点的最简实现
第一版可以设计得很小巧。每个表达式对象内部保存一个std::function，这个函数最终接受环境变量表并返回结果。
cpp复制class Expr {
public:
using EvalFn = std::function<double(const VarMap &)>;
explicit Expr(EvalFn fn) : fn_(std::move(fn)) {}
double eval(const VarMap &vars) const {
return fn_(vars);
}
private:
EvalFn fn_;
};
Expr lit(double value) {
return Expr{[value](const VarMap &) {
return value;
}};
}
Expr var(std::string name) {
return Expr{[name = std::move(name)](const VarMap &vars) {
return vars.at(name);
}};
}
Expr operator+(const Expr &lhs, const Expr &rhs) {
return Expr{[lhs, rhs](const VarMap &vars) {
return lhs.eval(vars) + rhs.eval(vars);
}};
}
Expr operator*(const Expr &lhs, const Expr &rhs) {
return Expr{[lhs, rhs](const VarMap &vars) {
return lhs.eval(vars) * rhs.eval(vars);
}};
}
于是调用方可以自然写出：
cpp复制Expr rule = lit(100) + var("level") * lit(3);
VarMap vars = {{"level", 5}};
double result = rule.eval(vars); // 115
这里的operator+、operator*只在构建表达式时返回新对象，并不立即求值。求值动作被延迟到调用eval那一刻。解释器被“折叠”进闭包层级里：每个Expr对象不知道自己对应常量还是二元运算，它只知道接受环境之后该怎么算。
4.3 这么写的好处和限制
好处是调用方基本察觉不到解释器的存在，几乎不需要学新语法。比如规则可以写成：
cpp复制Expr discount = when(level > 3, lit(0.8), lit(1.0));
通过更细致的内部DSL设计，整个业务表达式就是C++代码，变量名、函数名天然可读，IDE能提示，编译器能检查类型。这让规则引擎的维护体验非常舒服。
限制也明确：这种变体只能服务那些“由C++代码本身组装表达式”的场景。如果规则来自数据库、前端传参、外部配置文件，你仍然需要一个外部Parser把字符串解析成Expr。你不能要求业务同学一边写JSON，一边在JSON里嵌C++函数对象。所以这个变体适合做SDK，不适合做独立的脚本语言。
另一个工程隐患是性能。如果大量动态构建表达式，每个节点都包着std::function、按值捕获子表达式，拷贝和存储的开销偏高。如果只是几个少量规则，问题不大；要是每次请求都构建上万个表达式节点再求值，要谨慎，最好进入下一节要说的模板表达式方向。
5. 变体三：把解释时刻推向编译期的模板表达式形态
5.1 模板也可以构造“表达式树”，只是它活在类型层面
第4节的闭包版把运算符组合成运行时对象。如果去掉std::function的类型擦除，保留每个表达式节点的具体类型，就能得到Eigen等数学库里常说的表达式模板。运算重载返回的不是统一类，而是带有模板参数的节点类。于是表达式树的形状不再存在于堆上的一组对象中，而是存在于C++类型系统里。
看一个最简实现：
cpp复制template <typename L, typename R>
class AddExpr {
public:
L lhs_;
R rhs_;
AddExpr(L lhs, R rhs)
: lhs_(std::move(lhs)), rhs_(std::move(rhs)) {}
double eval(const VarMap &vars) const {
return lhs_.eval(vars) + rhs_.eval(vars);
}
};
class NumberExpr {
public:
double value_;
explicit NumberExpr(double value) : value_(value) {}
double eval(const VarMap &) const {
return value_;
}
};
class VariableExpr {
public:
std::string name_;
explicit VariableExpr(std::string name)
: name_(std::move(name)) {}
double eval(const VarMap &vars) const {
return vars.at(name_);
}
};
Num num(double value) { return Num{value}; }
Var var(std::string name) { return Var{std::move(name)}; }
template <typename L, typename R>
AddExpr<L, R> operator+(const L &lhs, const R &rhs) {
return AddExpr<L, R>{lhs, rhs};
}
这样一来，num(3) + var("x")的类型就不再是统一的运行时Expr，而是AddExpr<Num, Var>。求值依旧发生在运行期，因为x的值要到运行期才知道，但树的结构已经完全固化在类型里。编译器可以内联展开每个节点的eval，不需要进行虚函数分发或者std::function调用。这种“解释器结构固定、输入可变”的形态，非常适合高性能公式计算。
5.2 延伸一步：纯字面量场景里可以实现真正的编译期求值
如果表达式里全是常量，不再依赖运行期变量，理论上整个计算都可以提前完成。C++标准里用constexpr、consteval可以承担这个角色，C++20之后字符串解析甚至能在编译期做更多事。我一般不会用模板元编程硬写一个变态复杂的编译器，但会经常用这种手段验证公式模板是否正确：当所有叶子都传常量时，写一个static_assert做单元测试。
cpp复制static_assert(AddExpr<Num, MulExpr<Num, Num>>{...}.eval({}) == 7);
这类测试能使表达式模板在编译期跑通再进入运行期，定位问题的时间能省不少。
5.3 模板表达式的代价
听起来很香，但它不是万能的。第一，编译时间会显著上升，表达式链越长模板实例化越多，报错还容易出现一堆人类难以阅读的类型名。第二，大部分规则业务的“变量”来源于配置和运行时状态，单纯所有字面量固定并不常见。第三，如果想动态地从字符串构造模板表达式，是做不到的，模板实例化的类型必须在编译期固定。除非规则种类可枚举，比如系统预定义好了几十种公式模板，用配置选择采用哪一个。
因此我心目中模板表达式的定位是：在明确知道表达式组合种类有限、且高度追求运行性能时的一种解释器变体，而不是所有解释场景的默认答案。
6. 不同变体的选型边界，用一张对比表把话说明白
6.1 核心对比表
| 变体 | 运行时多态机制 | 适合语法结构 | 主要优势 | 主要代价 |
|---|---|---|---|---|
| 经典虚函数+继承 | virtual 分发 |
节点类型以后会持续增加 | 思路直观，容易教授 | 新操作难加，类 |