引言被“硬编码”逼出来的表达式解析做过程序开发的人十有八九都遇到过这种场景业务方递过来一句话——“帮我加个规则当订单金额大于一千用户等级是VIP并且库存小于50的时候触发预警”你听完第一反应是在代码里写if嵌套。写一次还好可怕的是这种规则每个月变三次每次变动都要发版上线改的人提心吊胆业务方还觉得你效率低。我早期在某个模拟监控项目中就踩过这个坑后来真正静下心研究了行为型模式里的解释器模式才逐渐明白这类“频繁变动、可组合、可计算”的规则和表达式正确做法不是写死在业务逻辑里而是定义一种小语法用代码把这个语法翻译成可执行的结构让规则变成数据。这也是解释器模式的核心价值——把一个频繁变化、看似复杂的问题抽象成可以被反复解析和求值的表达式树。这篇文章我会从原理讲到一整套可以落地的示例代码再把我实际使用过程中踩过的坑和排查经验一起分享出来适合正在学设计模式的人也适合想给自己的项目引入表达式解析能力但不知道从哪下手的开发者读完你至少能动手写一个自己的规则表达式解析器。1. 解释器模式到底在解决什么问题1.1 一句话定义和直白的理解方式解释器模式的定义说得很文绉绉给定一个语言定义它的文法的一种表示并定义一个解释器这个解释器使用该表示来解释语言中的句子。听起来像编译原理其实剥开看非常简单。它就是让你把“一句话”按规则拆成“一棵树”然后对这棵树做递归求值。语文课上分析句子成分“主谓宾定状补”拆成一个结构解释器模式干的就是类似的活把表达式“客户等级为VIP且金额大于一千”拆成两棵子树的组合左边判断等级右边判断金额中间用逻辑与连接最终输出一个布尔结果。理解这个模式最好的类比是计算器。你输入“35*2”计算器不会直接从左到右算而是先解析成树状结构乘法子树的优先级高于加法然后递归计算。解释器模式就是让你在自己的业务代码里拥有一个这样的小型计算器只不过算的不一定是数字可能是布尔值、字符串、日期、集合甚至是你自定义的对象属性。它属于行为型模式强调的重点是“算法的封装与运行时决策”而不是“对象的创建”或“结构的组装”。它适合的问题是有一类表达式频繁变化、种类有限但组合无限你不知道用户下一次会输入什么句子但你知道所有句子都由哪些基本元素组成并且每个元素如何求值。1.2 四大核心角色抽象表达式、终结符、非终结符、上下文要真正理解解释器模式必须把这四个角色吃透。它们不是空泛的概念而是你写代码时真实的类职责划分。第一个是抽象表达式AbstractExpression。它定义了一个统一的解释接口通常长这样定义一个interpret(Context ctx)方法所有节点都实现这个接口。抽象表达式是整个语法树的“公共接口”后续新增语法元素只需新增一个类实现它不用改动调用方。第二个是终结符表达式TerminalExpression。它表示语法树中的叶子节点自身不包含其他表达式。在规则引擎里常见的终结符有常量值“1000”变量引用“订单金额”单个比较运算“金额大于一千”——它也不再往下拆直接到变量运算符常量就结束了。终结符是递归的出口是整个语法树里真正干活的节点。第三个是非终结符表达式NonterminalExpression。它表示语法树中的分支节点内部至少持有一个子表达式引用。以“并且”为例AndExpression里面持有左表达式和右表达式两个字段解释的时候先递归解释左和右再把两个布尔结果求“与”。非终结符是组合的容器负责定义语法规则里的“关系”和“优先级”。第四个是上下文Context。它保存解释器执行时依赖的全局状态最常见的实现是一个Map里面塞了一堆变量名和变量值。同样一棵语法树在不同的上下文里解释会得到不同结果这就是“规则代码复用、数据驱动计算”的底层原理。角色的协作流程是这样的客户端先构造一棵语法树通常由解析器读取字符串生成然后调用根节点的interpret方法。根节点如果是非终结符就递归调用子节点的interpret如果是终结符就直接从上下文里面取数据做判断。一层层递归下去最终结果反馈回来。整个过程就是一个“树形遍历 递归计算”。1.3 为什么它属于“行为型”而不是“结构型”很多人会困惑解释器模式明明很依赖组合结构怎么归到行为型里去了这里需要理解设计模式分类的初衷。结构型模式关心的是“类和对象怎么组合成更大的结构”比如装饰器、适配器它们的核心产出是“组合关系本身”。解释器模式虽然内部也用了组合关系来构造成语法树但这只是手段它的核心目的是在运行时根据输入动态选择行为——同一个表达式这次为真下次为假本质上是一种行为计算策略。我见过很多人写解释器模式最后写成了纯数据结构堆砌原因就是只关注了“树怎么建”而忘了“行为怎么描述”。解释器模式的灵魂在于每个节点的interpret方法被设计成可递归、可独立求值的行为单元。行为型是它的内核树形结构只是承载行为的外壳。理解这一点能帮你在系统设计时抓住重点真正的收益不在树的构建而在节点行为的清晰定义与扩展能力。2. 从零实现一个告警规则表达式引擎2.1 用一个真实的模拟需求做承载理论说得再多也不如动手写一个能跑的示例我选择用“告警规则表达式引擎”这个场景来做讲解。假设某公司有一个监控运营大屏运维人员需要配置告警触发条件规则形如(订单金额 1000) (客户等级 VIP) !(库存 50)它支持逻辑运算符、||、!支持比较运算符、、、、、!支持括号改变优先级还支持字符串常量和数值常量混用。运维人员不写代码只需要在配置页面填表达式字符串系统需要随时解析并计算表达式在当前业务数据下是否成立。这个需求如果用传统if/else实现每增加一种运算符都要改核心判断逻辑散落的判断代码会越堆越多。用解释器模式整个过程是固定的字符串——词法解析成token——根据语法规则组装成语法树——对语法树递归求值。新增运算符只需要新增一个类核心解析逻辑几乎不用动。这就是这个模式最适合发挥的舞台。2.2 语法定义和上下文设计写解析器前一定要先把语法用清晰的语言定义出来我习惯用类似BNF的简化描述来表达。这个案例的语法可以定义为expression : orExpression orExpression : andExpression { || andExpression } andExpression : notExpression { notExpression } notExpression : ! notExpression | primary primary : ( expression ) | comparison | booleanLiteral | variable comparison : operand ( | | | | | ! ) operand operand : number | string | variable这个定义看起来专业其实就是在描述优先级括号最大其次是!然后是最后是||。你在实现递归下降解析器时完全按照这个优先级层级来写方法可以省掉大量处理括号和运算顺序的心智负担。上下文的实现我直接用一个MapString, Object来搞定键是变量名值是运行时数据。这一步看起来简单但有两个设计细节值得留意一是值类型不确定性很强解释器内部要做类型适配数值比较时统一转成double字符串比较时转为String二是取不到变量时怎么处理我倾向于返回null并用安全逻辑处理而不是直接抛异常因为一条规则里某个字段暂时没有数据是很常见的情况直接抛异常会导致整条规则不可用产生误报漏报具体做法在处理章节里细说。2.3 代码骨架表达式接口与终结符表达式代码实现从抽象表达式接口开始。一个干净的接口应该尽量精简只暴露求值能力public interface Expression { boolean interpret(EvalContext ctx); }上下文类则包装一个数据的Map并提供类型安全的取值方法。这道包装层别省它会让调用方代码干净很多public class EvalContext { private final MapString, Object data; public EvalContext(MapString, Object data) { this.data data; } public Object get(String key) { return data.get(key); } public double getNumber(String key) { Object value data.get(key); if (value null) return 0.0; if (value instanceof Number) return ((Number) value).doubleValue(); return Double.parseDouble(String.valueOf(value)); } public String getString(String key) { Object value data.get(key); return value null ? : String.valueOf(value); } }终结符表达式我设计三个类。第一个是VariableExpression表示一个变量引用解释时直接从上下文取对应key的值。第二个是ConstantExpression表示字面量比如表达式里的1000、VIP解释时直接返回自己持有的值。第三个是比较表达式ComparisonExpression它持有左操作数表达式、右操作数表达式和比较运算符解释时先递归求值左右两边再把类型归一化后按运算符比较。这里有必要放一下比较表达式的核心代码因为它是最像“叶子节点”的终结符public class ComparisonExpression implements Expression { private final Expression left; private final Expression right; private final String op; public ComparisonExpression(Expression left, String op, Expression right) { this.left left; this.op op; this.right right; } Override public boolean interpret(EvalContext ctx) { Object leftValue left.interpretValue(ctx); Object rightValue right.interpretValue(ctx); if (leftValue null || rightValue null) { return false; } if (leftValue instanceof Double rightValue instanceof Double) { double a (Double) leftValue; double b (Double) rightValue; switch (op) { case : return a b; case : return a b; case : return a b; case : return a b; case : return a b; case !: return a ! b; } } String a String.valueOf(leftValue); String b String.valueOf(rightValue); switch (op) { case : return a.equals(b); case !: return !a.equals(b); } throw new IllegalArgumentException(Unsupported operator: op); } }注意我的接口除了interpret还需要一个interpretValue方法返回原始值否则比较表达式没法处理变量和数字常量之间的比较。一种做法是让接口提供默认实现default Object interpretValue(EvalContext ctx) { return interpret(ctx); }这样终结符覆写即可非终结符不关心这个方法。这个细节在写代码时很容易漏漏掉的后果就是比较表达式不知道如何取变量值。2.4 非终结符表达式逻辑运算与优先级非终结符表达式负责把多个子表达式组合起来求值。AndExpression、OrExpression、NotExpression三个类逻辑上比较简单但要留意它们与“短路”相关的语义。AndExpression求值时如果左子表达式已经是false右子表达式不用再计算直接返回falseOrExpression相反左为true则直接返回true。短路不仅能提升性能还可以规避某些变量不存在时导致的异常——左半部分不满足条件时右半部分涉及的字段即使缺数据也不影响结果。public class AndExpression implements Expression { private final Expression left; private final Expression right; public AndExpression(Expression left, Expression right) { this.left left; this.right right; } Override public boolean interpret(EvalContext ctx) { return left.interpret(ctx) right.interpret(ctx); } }public class OrExpression implements Expression { private final Expression left; private final Expression right; public OrExpression(Expression left, Expression right) { this.left left; this.right right; } Override public boolean interpret(EvalContext ctx) { return left.interpret(ctx) || right.interpret(ctx); } }public class NotExpression implements Expression { private final Expression expression; public NotExpression(Expression expression) { this.expression expression; } Override public boolean interpret(EvalContext ctx) { return !expression.interpret(ctx); } }虽然AndExpression和OrExpression代码量很小但它们是整个语法树结构坍塌与否的关键。它们的存在让“组合无限”成为可能你可以依据它们造出一个几十层嵌套的表达式。如果哪天需求变成了支持和||混合优先级也不需要改这两个类只要解析器构建语法树时按正确层级挂载就行。2.5 递归下降解析器把字符串变成语法树有了语法节点还要有一个“编译器”把字符串转换成语法树。我采用最直观、也最适合解释器模式的递归下降解析法。它本质上就是按照语法分层定义几个方法每个方法对应一个语法层级。词法分析我做了简化用正则做token切分只支持数字、字符串、变量、括号、比较符、逻辑符这些基础token。实际项目中如果想支持更多语法可以引入一个真正的tokenizer层但思路完全一致。解析器的驱动入口public class RuleParser { private ListString tokens; private int pos; public Expression parse(String rule) { this.tokens tokenize(rule); this.pos 0; Expression expr parseOr(); return expr; } private Expression parseOr() { Expression left parseAnd(); while (match(||)) { Expression right parseAnd(); left new OrExpression(left, right); } return left; } private Expression parseAnd() { Expression left parseNot(); while (match()) { Expression right parseNot(); left new AndExpression(left, right); } return left; } private Expression parseNot() { if (match(!)) { return new NotExpression(parseNot()); } return parsePrimary(); } private Expression parsePrimary() { if (match(()) { Expression expr parseOr(); expect()); return expr; } Token t nextToken(); if (t.type TokenType.NUMBER) { return new ConstantExpression(Double.parseDouble(t.value)); } if (t.type TokenType.STRING) { return new ConstantExpression(t.value); } if (t.type TokenType.VARIABLE) { return new VariableExpression(t.value); } throw new IllegalArgumentException(Unexpected token: t.value); } }解析器里最需要注意的是循环配合递归的顺序parseOr内部先调parseAndparseAnd内部先调parseNotparseNot内部处理!和括号。这个顺序直接决定了运算符的优先级。如果我把放在了parseOr的上一层那么a || b c就会先算b c符合数学直觉。修改优先级最简单的方式就是调整方法之间的调用层级而不是在单个方法里加一堆复杂判断。关于词法分析我不建议在这个阶段做得太复杂能正确切分空格、括号、比较符、逻辑符就行。一个简单的正则切分方案可以做到先把两字符的比较符,,,!,,||匹配为整体再匹配单字符括号、!、数值常量和字符串常量、变量。强烈建议字符串常量用双引号包裹否则解析器和上下文都分不清它到底是变量还是字面量。2.6 调用方代码演示和整体效果这个案例的客户端调用非常简洁先构造一个上下文模拟本订单数据再传入规则字符串解析并求值public class RuleEngineDemo { public static void main(String[] args) { String rule (订单金额 1000) (客户等级 \VIP\) !(库存 50); Expression expr new RuleParser().parse(rule); MapString, Object orderData new HashMap(); orderData.put(订单金额, 1500.0); orderData.put(客户等级, VIP); orderData.put(库存, 30); EvalContext ctx new EvalContext(orderData); boolean result expr.interpret(ctx); System.out.println(该订单是否触发告警: result); } }当订单金额1500、客户等级VIP、库存30时结果为真触发告警如果把订单金额改成800解析器不需要重新编译同一棵语法树在另一个context下求值即可结果自动变为false。这种模式天然实现了“规则与数据分离”规则字符串可以存在数据库、配置中心或前端界面后端运行时只负责解析与求值。整个案例完整代码量不到四百行却已具备一个商用表达式引擎的核心能力。3. 设计过程中的关键取舍和思考3.1 为什么不用策略模式硬编码有经验的朋友可能会问这个需求用策略模式也能做定义一个RuleStrategy接口每个规则一个实现类运行时用工厂选择对应策略不也能搞定吗确实能但有一个本质差异策略模式适合“候选策略数量固定且已知”的场景比如支付方式有支付宝、微信、银行卡三种枚举清清楚楚而规则表达式的组合随数量和逻辑运算符呈指数爆炸比如(订单金额 1000) (客户等级 VIP) (下单时间 2024-01-01)类似的组合不知有多少种为每一种组合写一个策略类写代码的人很快会疯掉。解释器模式的价值就是把“组合能力”本身做成可复用的语法节点你只需要维护基本的终结符和非终结符组合的无限性由语法树自动产生。3.2 和组合模式的关系语法树的天然共生解释器模式内部大量借用了组合模式的思想——非终结符持有子节点叶子节点无子节点这正是组合模式的典型结构。区别在于组合模式关注的是“整体与部分的一致性”比如目录树、菜单树客户端可以用相同方式对待单体和容器而解释器模式的每个节点除了结构还自带行为方法interpret递归时把子结果向上汇总。实际编码时我可以建议你复用组合模式的经验统一抽象接口、容器节点持有子节点列表、叶子节点不做递归聚合。两者配合起来表达能力很强特别是当表达式语法树需要支持序列化、持久化、界面可视化展示的时候组合模式的遍历能力能派上大用场。3.3 运算符优先级与括号处理的设计要点优先级是整个解析器最容易翻车的地方。我见过不少新手把优先级混在同一个方法里比如先找再找||最后处理!结果代码里到处是嵌套的while循环新增一个运算符仿佛在拆炸弹。正确的做法就是严格按语法分层来。拿!举例它的优先级高于所以它应该在parseNot层级被消费。而比较运算的优先级是最低的所以parsePrimary里遇到变量或常量后要立刻往后看是否是比较符如果是就消耗掉后面两个操作数拼成ComparisonExpression。括号则是“提升优先级”的工具遇到(进入一个新递归遇到)结束当前递归自然形成了优先级控制。经验之谈在解析器里方法的调用层级就代表着运算符的优先级。想清楚这一点你写代码时几乎不需要再关心“优先级表”只要维护好方法调用的嵌套顺序就够了。3.4 如何优雅地扩展新运算符解释器模式最被称道的就是扩展性。如果要支持新的比较运算符比如模糊匹配contains只需要三步第一步新增一个终结符表达式类或者在ComparisonExpression里增加contains分支第二步更新词法分析让contains能被识别为token第三步在解析器的比较表达式处理逻辑里加入对contains的识别。原来的AndExpression、OrExpression、NotExpression什么都不用改调用方不用改。如果某种新运算符的优先级介于现有层之间需要新增一个语法层级方法则修改parseOr或parseAnd的调用链即可其他类依旧不受影响。这种“开闭原则”带来的维护体验对长期演进的项目来说价值很大。4. 常见问题、踩坑记录与优化手段4.1 性能瓶颈到底在哪以及如何破解解释器模式最常被质疑的点就是性能。如果每条规则每次求值都重新解析字符串性能确实不理想——词法分析、语法树构建、字符串split、正则匹配都是CPU密集操作。但本质上这是“解析”和“求值”没有分离导致的。把过程拆开看解析一个规则字符串的成本远高于求值成本。所以正确优化姿势是把解析结果缓存起来成为一棵语法树语法树可以被任意次、任意上下文的求值复用。缓存粒度一般是一个规则ID对应一棵AST。规则不变解析一次后续每次求值都走递归速度可以提升一到两个数量级。另外一个容易被忽视的优化点是短路求值。AndExpression中左表达式为false时右表达式不会执行OrExpression左为true时右不执行。这个特性可以让很多传入的无效数据被天然过滤掉既省了时间又避免了取值异常。到现在我这个实现已经能覆盖绝大多数业务场景。4.2 递归深度太深导致栈溢出解析器和求值器都是递归实现的如果一个规则写了几百层嵌套括号StackOverflowError就会找上门。规则表达式一般来说不应该长到那种程度但作为防御方案我习惯在解析器里加一个深度计数器每进入一层parsePrimary就加一超过阈值比如64层就抛出“表达式嵌套过深”的检查异常。这个参数可以做成配置项方便大表达式业务调整。加这个防御机制不是为了挡住恶意用户而是为了防止意外的递归死循环把整个服务打挂。4.3 变量不存在或类型不一致的运行时异常生产环境里最常见的异常来源不是逻辑错误而是上下文数据缺失或类型不对。比如规则里写了库存 50但某条数据根本没有库存字段。如果不加保护解释器抛NPE会让整条规则求值失败进而影响告警准确性。我的处理策略是在上下文取值方法里做安全兜底数字取不到值时返回0字符串取不到返回空串。同时ComparisonExpression只在左右值都为有效对象时才比较否则返回false。这样做的代价是某些“字段缺失”场景可能被静默处理为不告警但业务上通常更愿意接受“少报”而不是“服务崩溃”。需要在“严格性与可用性”之间做取舍时我通常会让上下文类提供containsKey方法由上层业务决定是否需要验证字段完整性。4.4 帮助线上排查问题的几个调试技巧解释器模式的代码一旦出问题肉眼很难看出是解析器的问题还是某个节点求值的问题。我在排查这类问题时的三步走方法是先打印语法树再打印上下文最后单独跑子表达式。打印语法树最简单的方式是给每个表达式类实现toString方法比如AndExpression重写为(left right)这样打印根节点就能还原出整棵树的形态。排查时一旦发现语法树和你预期不一致那问题大概率出在解析器如果树正确但结果不对直接在抽象表达式接口加一个default调试方法打印节点类型、变量值、计算结果逐层排查。另外我强烈建议给解析器加一个“单测保护网”把常见的运算符组合、括号嵌套、短路逻辑、缺失变量、不同数据类型比较五类场景全部用JUnit参数化测试覆盖住改动后的回归问题能被第一时间揪出来。4.5 什么时候不要用解释器模式解释器模式并不是银弹哪些场景不应该用需要时刻提醒自己。如果表达式语法极其简单比如只有一种固定格式的“等于判断”那直接用if/else比写一个解释器清晰得多。如果语法模型复杂到需要上下文无关文法级别的描述比如支持赋值语句、循环、函数调用那你应该考虑引入业界成熟的表达式引擎或规则引擎而不是自己重复造轮子。如果项目里只需要处理几个有限规则且长期稳定解释器模式反而让代码变得臃肿。设计模式本身就是一种“权衡”用错模式的成本往往比不用还高。解释器模式真正发光的领域我总结下来有三个特征一是规则频繁变动今天这个阈值明天那个阈值二是规则基础元素可控无非变量、常量、比较、逻辑运算、数学运算那几类三是规则组合方式无穷无尽而且由非技术人员在界面上配置。你回头看是不是典型的规则引擎、动态告警、权限表达式、工单路由配置都长这个样子抓住这三个特征你就能比较准确地判断要不要引入这种模式。5. 更深层的扩展思路与个人总结5.1 从布尔表达式走向更复杂的AST如果看完上面的案例你脑袋里冒出来一个问题——“我业务里不只是布尔判断我还要算分成比例、算折扣金额”那恭喜你思路已经打开了。解释器模式的应用远不止于布尔表达式它可以扩展到数值表达式。方法只需要一个调整抽象表达式接口不再返回boolean而是返回一个Object数字运算返回Double布尔运算返回Boolean字符串拼接返回String。这样整个语法树就从“规则判断树”升级为“通用表达式树”可以支撑类似(订单金额 * 0.8) 100这类带算术运算的表达式。这就是AST抽象语法树思想的源头很多低代码平台和规则引擎的实现本质上就是一棵这样的“活树”。5.2 规则持久化与动态加载的设计心得实际业务里规则表达式字符串通常存在数据库里。每次上线一个新的规则只需要向库里插入一条记录服务端启动时或者规则变更回调里解析并缓存AST即可。这里有一个很重要的经验尽量别把AST序列化到数据库里存原始字符串就够了。AST结构是Java类实例跨语言、跨版本都不友好一旦类结构变化旧序列化数据直接作废。把原始字符串作为“单一事实来源”AST只是内存缓存反而最干净。如果担心解析失败可以在保存规则时做一个“预解析校验”用解析器跑一遍看看语法是否合法不合法就不允许保存这样线上永远不会出现坏规则。5.3 我用了这个模式后的真实感受说起来我最初学习解释器模式时觉得它抽象、绕甚至怀疑这种模式没什么实用价值。直到我真的把它用在了一个需要频繁动态调整规则的项目里才体会到它的魔力需求方在地铁上想出一个过滤规则直接发到配置后台连发布都不需要系统立刻生效。以前同样一个需求先要写代码、自测、提测、上生产快则半天慢则一两天。两种体验摆在一起才知道省下的不是一点半点。如果你准备在自己的项目里尝试解释器模式我有几条比较实在的建议先把需求里的语法用BNF或简单的语法规则写清楚写不清楚的语法一定写不清楚代码优先实现最小可用的语法子集跑通完整链路后再逐步加运算符而不是一开始就贪多求全一定要为解析器和每个节点写单测尤其是那些组合型和边界型用例它们绝对会在将来的某次重构里救你一命最后记得在接口设计时预留interpretValue之类的元数据能力别等到要支持数值表达式时再拓宽接口那时候改动的成本会变大。解释器模式是那种“看着没什么存在感、但真正用上后会带来长期回报”的设计模式。理解它不需要背多少理论知识核心就是掌握“语法——语法树——递归求值”这三板斧。一旦你亲手写过一个可扩展的规则引擎再回头阅读它的源码和资料你会发现很多原本模糊的概念都会自己变得清晰起来。
