写代码这些年有个有意思的现象一说“设计模式”大家最喜欢围观的是单例、工厂、观察者而解释器模式总是被一笔带过。书上的定义也写得云山雾绕不外乎“定义文法、解释句子”配上抽象语法树AST的叫法看着就劝退。但真正做过表达式引擎、规则引擎、模板解析器、甚至写过简单脚本解释器的人早晚都会撞上它——那时候书上的标准结构往往不是最顺手的东西折腾几轮之后你手里那套“变体”才是真能落地的方案。这篇文章不打算复述教科书。我想从一个实际入手过的表达式求值器说起拆清楚解释器模式在C里为什么这么别扭然后逐个讲我在工程里真正用过的四种变形把AST“压平”成计算结果宿主的做法、用Visitor分离遍历逻辑的做法、把解释规则直接变成回调的做法以及把解释挪到编译期的模板元编程变体。每种都会给可直接参考的代码骨架、适用边界和坑位最后再做一张选型对照表。适合已经能熟练写C的读者也适合准备做规则引擎、DSL解析或者脚本功能、想少走弯路的朋友。1. 先搞清楚经典解释器模式为什么在C里很别扭1.1 一次完整的“教科书用法”演示先别急着聊变体得先知道我们在给什么打补丁。解释器模式的核心其实只有三件事文法、语法树、解释器。以最简单的算术表达式为例假设我们支持数字、变量和加减乘除四则运算按教科书写法大概是这个样子#include map #include memory #include string #include stdexcept using Vars std::mapstd::string, double; class Exp { public: virtual ~Exp() default; virtual double eval(const Vars vars) const 0; }; class Num : public Exp { double val; public: explicit Num(double v) : val(v) {} double eval(const Vars) const override { return val; } }; class Var : public Exp { std::string name; public: explicit Var(std::string n) : name(std::move(n)) {} double eval(const Vars vars) const override { auto it vars.find(name); if (it vars.end()) throw std::runtime_error(unknown variable: name); return it-second; } }; class BinaryOp : public Exp { char op; std::shared_ptrExp lhs, rhs; public: BinaryOp(char o, std::shared_ptrExp l, std::shared_ptrExp r) : op(o), lhs(std::move(l)), rhs(std::move(r)) {} double eval(const Vars vars) const override { double a lhs-eval(vars); double b rhs-eval(vars); switch (op) { case : return a b; case -: return a - b; case *: return a * b; case /: if (b 0.0) throw std::runtime_error(divide by zero); return a / b; } throw std::runtime_error(unknown op); } };配合一个递归下降解析器(x 1) * 2会被解析成这样的树BinaryOp(*) / \ BinaryOp() Num(2) / \ Var(x) Num(1)然后调用root-eval(vars)整棵树自上而下递归求值结果就出来了。1.2 这套结构在真实工程里的两个“硬伤”第一个硬伤是对象即节点节点即所有权。上面每个语法单元都是一个多态对象用shared_ptr串起来形成链式所有权。这在语法树不大、生命周期清晰的场景没问题可一旦树被来回传递、跟其他模块纠缠所有权就会变得像麻线团。等你要做“对AST做多趟处理”或“在不同阶段保存状态”的时候每趟访问都要重新写一遍if (auto v dynamic_castVar*(node.get()))这样的类型分派代码又丑又脆——加一个新节点类型所有处理点都得跟着改。第二个硬伤是遍历逻辑和解释逻辑绑死在每个节点上。教科书给每个节点都安一个eval()这是“把动作塞进节点内部”的做法和很多真实场景是冲突的。比如我想做三个动作打印表达式、检查变量是否都定义、实际求值。按教科书方式就是往Exp里加三个虚函数再加第三个动作时又要动所有子类。C不像Java动不动就开IDE自动补全这种“改一个接口改一百个类”的操作很容易漏。2. 变体一把AST“压平”成计算结果宿主丢掉树结构2.1 思路转变不是所有场景都值得建一棵长期存活的树有的表达式根本不需要长期保留解析完就求值求完值就扔。典型场景包括Excel公式的临时校验、告警规则里的阈值判断、配置系统里的布尔表达式求值。如果不打算反复遍历这棵树那建一棵“持久化AST”就是纯浪费——每个节点小、数量多堆上到处都是小对象碎片。我的做法是让每个表达式节点自己携带求值环境和计算结果从下往上“归约”直接收敛成一个最终值。这本质上是一个“以值为主、以树为辅”的宿主模型。这里给一个去掉多态节点、改造成结构型方案的核心示意struct Formula { // 表达式“编译”后的形式持有环境闭包和函数语义 std::functiondouble(const Vars) eval; }; Formula makeNum(double v) { return Formula{ [v](const Vars) { return v; } }; } Formula makeVar(std::string name) { return Formula{ [name std::move(name)](const Vars vars) - double { auto it vars.find(name); if (it vars.end()) throw std::runtime_error(unknown variable: name); return it-second; }}; } Formula makeBinary(char op, Formula l, Formula r) { return Formula{ [op, l std::move(l), r std::move(r)](const Vars vars) - double { double a l.eval(vars); double b r.eval(vars); switch (op) { case : return a b; case -: return a - b; case *: return a * b; case /: return b 0.0 ? throw std::runtime_error(divide by zero) : a / b; } throw std::runtime_error(unknown op); }}; }仔细看这里Formula只有std::function不再有虚函数不再有std::shared_ptrExpBinaryOp节点变成了一个持有两个Formula的结构。解析器构造的每一层都通过lambda捕获下层的结果组装为一个“可执行闭包”。整棵AST被“压扁”成一层层回调的调用链运行时直接展开求值不需要反向拆指针。2.2 什么时候该用这个变体这种写法我主要是用在小体量的公式/规则引擎里。比如电商结算的满减规则一条规则就一个Formula结构小巧、复制成本低、所有权清晰。它解决的核心问题有删除“AST长期驻留”的需求求值完成后内存释放非常干净天然支持表达式作为头等值可以在容器里存一组Formula比如条件优先级列表因为没有多态基类那份std::function本身就是类型擦除容器接口更干净不过你也会立刻发现它的代价std::function通常要额外分配内存来持有捕获的lambda表达式嵌套深时构造和调用的开销都比纯虚函数版本高。对于每秒几百万次的小表达式求值这不是最优解。真要压性能还得看变体四那种编译期思路。3. 变体二Visitor把“节点结构”和“遍历动作”彻底拆开3.1 为什么要拆加动作比加类型更容易发生回到那棵教科书AST。如果代码里已经定义了Num、Var、BinaryOp这些节点现在要支持打印、求值和变量检查三个动作。你当然可以去每个类里加三个虚函数但更好的思路是引入一个访问器Visitor把动作全部外置。C里比较顺手的实现是用经典的acceptvisit模式class Exp; class Num; class Var; class BinaryOp; class Visitor { public: virtual ~Visitor() default; virtual void visit(const Num) 0; virtual void visit(const Var) 0; virtual void visit(const BinaryOp) 0; }; class Exp { public: virtual ~Exp() default; virtual void accept(Visitor v) const 0; }; class Num : public Exp { double val; public: explicit Num(double v) : val(v) {} double get() const { return val; } void accept(Visitor v) const override { v.visit(*this); } }; class Var : public Exp { std::string name; public: explicit Var(std::string n) : name(std::move(n)) {} const std::string getName() const { return name; } void accept(Visitor v) const override { v.visit(*this); } }; class BinaryOp : public Exp { char op; std::shared_ptrExp lhs, rhs; public: BinaryOp(char o, std::shared_ptrExp l, std::shared_ptrExp r) : op(o), lhs(std::move(l)), rhs(std::move(r)) {} char getOp() const { return op; } const Exp getLhs() const { return *lhs; } const Exp getRhs() const { return *rhs; } void accept(Visitor v) const override { v.visit(*this); } };然后用具体Visitor实现不同动作。求值Visitor大致长这样class EvalVisitor : public Visitor { public: // 因为要递归处理子节点这里不能像教科书里“每个节点自己eval” // 而是用 Visitor 主动去 accept 子节点再把值带回父节点。 };实现细节里比较有意思的是visit(const BinaryOp)时需要递归访问左右子树这里需要某种上下文携带返回值。最简单的做法是Visitor内部持有栈遇到数字就压栈遇到二元运算就弹出两个计算再压回结果。这样所有状态都在一个Visitor对象里非常灵活。我自己在真实场景中更多是用它做“多趟处理”第一趟Visitor检查变量未定义引用第二趟Visitor做常量折叠第三趟Visitor生成指令或直接求值。这比在每个节点里塞apply()方法干净得多。缺点也很明显——节点类型一多Visitor里要写的visit函数就跟着膨胀每加一种节点所有Visitor都得同步补一个方法。3.2 用std::variant实现免修改的Visitor如果节点种类稳定还有更现代的玩法不用多态直接用std::variant表达节点类型配合std::visit分发。比如struct Num { double val; }; struct Var { std::string name; }; struct BinaryOp { char op; std::shared_ptrNode lhs; std::shared_ptrNode rhs; }; using Node std::variantNum, Var, BinaryOp; double evalNode(const Node n, const Vars vars) { return std::visit(overloaded{ [](const Num v) { return v.val; }, [](const Var v) { return vars.at(v.name); }, [](const BinaryOp b) { double a evalNode(*b.lhs, vars); double c evalNode(*b.rhs, vars); // 返回四种运算 } }, n); }std::variant版本的优势是“穷尽性”检查由编译器保证新增一个节点类型后不用你在运行时到处写dynamic_cast只要编译一下编译器会指出每个没有覆盖新类型的std::visit地点。代价是递归结构写起来没有虚函数直观调试时也稍微麻烦一点。两种Visitor我实际都用过个人观感节点数量少、变化少选variant更省心变化频率高、动作多传统抽象基类Visitor能少写不少类模板。4. 变体三函数优先的“解释器即回调”风格4.1 不再建模“语法”直接建模“语义动作”前面两种变体都还是在建模“语法树”——要么用多态对象要么用variant。但从规则引擎的真实需求看很多“表达式”压根不用建树直接把规则语义写成回调链就完了。比如一个告警规则CPU使用率 90 且 持续5分钟。拆开来看就是“大于”“且”“求值”“持续分钟数”这几个动作回调套回调就是最自然的表达方式。这种变体的核心是把“解释过程”内嵌在函数组合里。用一个简单的实现演示using Env std::mapstd::string, double; using EvalFunc std::functiondouble(const Env); struct Rule { std::string name; EvalFunc condition; // 满足条件时执行的动作列表 std::vectorstd::functionvoid(const Env) actions; }; EvalFunc makeThresholdRule(std::string metric, double limit) { return [metric std::move(metric), limit](const Env env) - double { auto it env.find(metric); if (it env.end()) return 0.0; // 指标缺失视为不满足 return it-second limit ? 1.0 : 0.0; }; } EvalFunc makeAnd(EvalFunc a, EvalFunc b) { return [a std::move(a), b std::move(b)](const Env e) - double { return (a(e) ! 0.0) (b(e) ! 0.0) ? 1.0 : 0.0; }; }懂的人一眼能看出来这是在把解释器模式跟回调/策略模式混着用语法树被“语义化”每种规则本身就是函数对象。4.2 应用场景和注意点我在做配置化数据清洗工具时用过这个变体。业务方不是程序员不可能传C代码进来只能传JSON配置。我们把JSON解析成一组Rule对象每个规则内部的EvalFunc由配置文件驱动生成。这个方案最核心的好处是规则之间可以自由组合and/or/not/时间窗口每个规则又各自是个完整可测试的单元单测覆盖成本很低。但要注意的是这种写法没法“看到”表达式内容一旦调试需要打印规则逻辑就只能靠为每个EvalFunc额外附加描述字符串或者统一打日志看入参出参。如果你需要动态生成代码、做AST反推、或者把用户输入的表达式原样回显这个变体会很难受。另外一个坑是递归组合产生的栈风险。规则嵌套几十层时回调链也会嵌套几十层虽然不至于爆栈但如果你在外面包了类似std::function的深层拷贝传参性能会肉眼可见地下降。实务上我建议每个EvalFunc内部只捕获小对象环境通过参数传入不要在不必要时层层捕获大vector。5. 变体四把解释器塞进编译期用模板和constexpr执行5.1 谁说解释一定要在运行时如果你处理的表达式本身就是编译期常量比如配置文件里写死了kMaxValue 2 * 1024 13完全没必要在运行时解释。C17起constexpr能力大幅增强字符串解析都能放在编译期完成。把解释器模式做进编译期是真正的“变体”。一个最简单的编译期数值表达式求值器可以这样写#include string_view #include utility constexpr bool isDigit(char c) { return c 0 c 9; } constexpr double parseNumber(std::string_view sv) { // 解析一个数字并推进 sv } constexpr double parseTerm(std::string_view sv) { // 处理 * 和 / } constexpr double parseExpr(std::string_view sv) { // 处理 和 - } constexpr double evalConstExpr(std::string_view expr) { return parseExpr(expr); } static_assert(evalConstExpr(2 * 10 5) 25.0);这里的parseExpr就是一个编译期递归下降解释器static_assert保证了如果表达式语法错误编译直接失败。现实里我很少写这么纯粹的编译期解释器但相关的思路在表达式模板Expression Templates里用到飞起——Eigen矩阵库就是通过模板把a b * c这种表达式解释成计算图并生成高效的代码路径而不是产生一个运行时对象再逐层调用。5.2 边界条件和注意事项编译期解释器最爽的点是零运行时开销bug发现得早但它也最能坑人。首先编译期递归深度有限制表达式层数深了会直接把编译器卡爆报错信息还极其难看。其次不是所有代码都能放到constexpr函数里C20之前std::vector能用了但很多STL算法还不行字符串操作也受限制。最后“解释结果”必须在编译期可见才有意义如果真是运行时来自用户的表达这条路完全白搭。所以我的判断是这个变体更接近“工程优化”不是解释器模式的主干用法。只有当你的表达式是配置的一部分、每次启动前就知道全部输入时才值得把解释器模板化。否则老老实实用前三种运行时方法别给自己找罪受。6. 实战选型四种变体对照表与C踩坑实录6.1 一张表看清要不要用某个变体变体核心形态内存代价扩展方向最擅长的场景最怕的场景教科书AST多态节点虚函数中节点多且散加动作要改类教学演示小规模DSL复杂语法多趟处理计算结果宿主std::function闭包中lambda捕获表达式像值一样传递规则引擎、公式模板需要回显AST、频繁构造销毁Visitor/ASTacceptvisit中需维护栈加动作对外置多趟遍历、代码生成节点类型频繁新增variant版Visitorstd::variantstd::visit较低扁平存储编译器穷尽检查稳定节点集分层处理递归深度大、成员多编译期解释器constexpr/模板实例化零编译后不存在静态配置求值启动初始化、编译期校验运行时用户输入复杂错误提示表里的“怕”不是不能做是性价比低。比如教科书AST也能加Visitor只是要写额外一次分发代码会变胀std::function版本也不是不能回显语法树只是每个closure都得带上描述字符串成本高。6.2 我在实操中反复踩过的几个坑第一个坑是循环引用导致内存泄漏。教科书里树结构常用shared_ptr指向子树但如果你给父节点一个parent指针指向父级很快会形成环。现实中我见过一个规则引擎每个节点保存父指针方便错误定位结果整棵表达式树永远释放不掉老项目CPU稳中带涨排查几天才怀疑到这儿。解法很简单所有权用唯一指针或值存储非必要不加反向指针否则反向指针必须是无所有权的裸指针/弱引用。第二个坑是解析错误定位难。“第几行第几列出错”是编译器才有的奢侈。自己实现解释器时最容易忽略的是错误上下文。后来我在每个节点构造函数里顺手记录sourcePosition源文本偏移量解析到哪一段就把它传进去报错时至少能把出错片段打印出来。这个习惯让我做表达式引擎时被坑的次数骤减。第三个坑是递归下降解析器没有处理“优先级左结合”。做加减乘除容易一加上比较、逻辑、一元负号文法就开始乱。我吃过一次亏后干脆固定成“一层一个优先级的函数”模板parseExpr - parseTerm - parseFactor - parsePrimary再往上加优先级逐层增加函数。缺点是函数越来越多优点是每层都极其简单单测能覆盖到。第四个坑我多说两句表达式注入。规则引擎的输入来自配置或者用户很多人想当然地以为是自己人写JSON不怕。但真到业务流程里这条配置可能一路传到你解析器前面。解析器要明确拒绝过于深的嵌套、限制节点总数到达warning阈值、对变量名做白名单。别等出事了再补事故一旦发生追查一个远端下发的坏表达式是非常痛苦的过程。写在最后的个人体会早期写解释器模式我总想着一步到位建一棵“教科书级”AST然后什么都能干。后来做计费规则、指标告警、数据清洗脚本被多趟遍历和内存管理反复折腾之后才意识到解释器模式最大的价值不是“别家怎么写我也怎么写”而是“怎么把语言处理流程拆成一堆可以单独演化的小部件”。四种变体说明白了其实都是在回答同一个问题——阶段状态放哪、遍历动作怎么分发、语法结构要不要长期驻留。根据手头的真实场景选一个顺手的方向去组合远比强行套用某个设计模式图省事得多。说实话代码写多了就会发现最优雅的设计永远不是模式本身而是模式在你那个具体问题里被剪裁过的样子。