企业官网建设流程全解析

前阵子接了个规则配置平台的需求，底层的过滤条件要支持运营在后台直接配置，类似“活跃天数大于30 AND (积分等级高于3 OR 白名单用户)”这种表达式。第一版我用 if-else 写硬逻辑，产品改了三轮规则之后，代码已经没法看，后来重构时把规则字符串解析成语法树，才真正吃透了设计模式里的解析器模式（Interpreter Pattern）。

解析器模式的本质，是把一个自定义语言的文法规则映射为一组对象，再用组合结构表达“一条规则的组成部分”，最后由每个对象各自完成解释动作。它特别适合体量不大、语法相对稳定、但是业务规则经常变化的场景。这篇就结合实际代码聊聊这个模式的落地方式，包括角色拆解、AST构建、递归下降解析，以及几个我跳过的坑。适合已经写过业务代码、想系统提升设计能力的同学，也适合准备把“配置化”落到实处的后端开发。

1. 解析器模式的本质：把“语法规则”变成“对象结构”

1.1 从一段规则字符串说起

假设运营后台配置了这样一条规则：

活跃天数 > 30 AND (积分等级 > 3 OR 白名单用户)

计算机拿到这条字符串，不能直接执行。它需要做两层处理：第一层是词法分析，把字符串切分成有意义的单词和符号；第二层是语法分析，按照预定义的文法生成抽象语法树（AST）。解析器模式的核心工作，就是围绕这棵语法树的构建和解释展开。

这里说的 AST，你可以把它理解成一颗“表达式的树”。

• 根节点是整条规则；
• 内部节点是运算符，比如 AND、OR、大于；
• 叶子节点是变量、常量，比如“活跃天数”“30”。

判断一条记录是否符合规则时，就从根节点开始递归往下求值，左子树算一遍，右子树算一遍，再根据当前节点的类型做一次合并。整个过程很自然，因为树的递归结构和表达式的递归定义天然对应。

1.2 四个核心角色：AbstractExpression、Terminal、NonTerminal、Context

经典设计模式书里把解析器模式拆成四个角色，我建议不要死记角色名，直接对应到代码里会更清楚。

在实现时，我会尽量不硬套 Context 类。如果只是保存变量绑定，一个 Map 就够了。只有当解释器需要注册函数、保存类型信息、或者表达式之间需要共享中间结果时，才值得单独抽一个 Context 类。设计模式是思想，不是教条，怎么简单怎么来。

还有一个很容易被忽略的点：新增一种语法规则，往往只需要新增一个表达式类，以及对应的一小段解析逻辑。这就是开闭原则在这类场景里的体现——对扩展开放，对修改关闭。老代码不用动，新规则可以加。这也是解析器模式最大的价值。

1.3 和正则、硬编码相比，到底赢在哪里

很多人看到这种需求的第一反应是“用正则”。正则确实是好东西，但它擅长的是线性文本匹配，不是递归结构。比如(A AND (B OR C)) AND D这种多层嵌套，正则写起来会非常痛苦，因为它本质上没有“递归展开”的能力。更别提规则里还要做类型转换、字段映射、运行时变量绑定这些事。

硬编码 if-else 也不是不行，规则少的时候最快。但规则一多，每个条件分支都要写一遍，排列组合会爆炸。产品说“加一个积分等级判断”，你就要钻进业务类里改一坨 if 的长链，测完上线，过两天又改。那时的维护成本已经不亚于写一个简单解析器了。

我自己的判断标准是：如果规则数量超过 10 条、且未来大概率会持续增加，或者规则语法要支持嵌套和优先级，那就应该认真考虑解析器模式。

2. 设计思路拆解：先有文法，再写代码

2.1 语法树为什么天然是组合模式

要理解解析器模式，先要理解组合模式。组合模式的核心思想是：把“叶子节点”和“组合节点”都看作是同一种东西，客户端可以一致地对待它们。

在我们的规则表达式里：

• 叶子节点是变量、常量；
• 组合节点是 AND、OR、NOT 这些运算符。

不管当前节点是变量还是 AND 表达式，对外都只需要提供一个一样的动作：解释求值。变量的解释动作是“查上下文返回布尔值”，AND 解释动作是“先算左子树，再算右子树，两个都真才返回真”。由于接口完全一致，求值函数就能递归地完成整棵树的遍历。

这是一个典型的递归结构：一个 AND 节点内部可以包含另一个 AND 节点，再里面还可以包含 OR 节点。组合模式恰恰擅长表达这种“整体-部分”的递归层级。所以解析器模式本质上是在组合模式提供的结构之上，增加了一层“解释执行”的语义。

2.2 先写文法：BNF 定义与优先级设计

很多人拿到需求直接写代码，写一半发现括号不知道丢哪里去了，运算符优先级处理得稀烂。我的建议是，动手前先把文法写出来。

我这里用的是扩充的巴科斯范式，也就是常说的 BNF。不需要深入了解理论，把它理解成“描述语言文法的公式”就行。对于布尔规则，我可以这样定义：

rule := orExpr EOF; orExpr := andExpr ( 'OR' andExpr )*; andExpr := notExpr ( 'AND' notExpr )*; notExpr := 'NOT' notExpr | primary; primary := '(' orExpr ')' | 'true' | 'false' | VARIABLE;

这段文法的意思很简单：

• 一条完整的规则，是一个 orExpr 然后结束；
• or 表达式由一个 and 表达式后面跟零个或多个 OR 组成；
• and 表达式由一个 not 表达式后面跟零个或多个 AND 组成；
• not 表达式是 NOT 后面跟一个 not 表达式，或者直接是一个 primary；
• primary 可以是括号括起来的 or 表达式，也可以是布尔常量，还可以是一个变量名。

优先级完全靠这个层层嵌套的引用关系实现：NOT 比 AND 高，AND 比 OR 高。这个设计后面会直接映射到递归下降解析器的几个函数上：parseOr 调 parseAnd，parseAnd 调 parseNot，parseNot 调 parsePrimary。先花十分钟把 BNF 写清楚，后面写 Parser 只需要照着翻译。

2.3 解析器模式不是“写个 parse 方法”就完了

我遇到过不少同学，把解析器模式理解成“写一个 parse 方法处理字符串”。这个理解是偏的。parse 或者 Parser 只是前半段——把字符串变成语法树；真正的解释执行，是让这棵语法树自己会“跑”。

换句话说，解析器模式包含两个重要阶段：

1. 解析阶段：把字符串变成 AST；
2. 解释阶段：对 AST 递归求值，得到结果。

很多讲设计模式的资料只盯着“抽象表达式”和“终结符表达式”讲，忽略了最关键的 Parser。结果就是读者学会了四个角色，但拿到一条真实规则字符串还是不知道从哪下手。所以我在实际落项目时，会重点把 Tokenizer、Parser、Expression 三者一起设计出来。这样代码既有模式的味道，又能真正跑起来。

3. 核心实现：规则引擎从零落地（附代码）

3.1 抽象表达式与终端表达式：先定义统一接口

我用 Java 来演示，但思路是语言无关的。先定义接口：

public interface Expression { boolean interpret(Map<String, Boolean> context); }

这个接口是所有语法树节点的统一入口。这里有个设计上的关键点：接口方法接收 context，但不要求在表达式内部保存这个 Map。这样设计的好处是，表达式对象本身是无状态的，多个线程可以共享同一个 AST，解释时只要分别传入各自的 context 就行。

终端表达式先来一个变量表达式，对应文法里的 VARIABLE：

public class VariableExpression implements Expression { private final String name; public VariableExpression(String name) { this.name = name; } @Override public boolean interpret(Map<String, Boolean> context) { Boolean value = context.get(name); if (value == null) { throw new IllegalStateException("未绑定变量: " + name); } return value; } }

解读 DOM Element 的时候，叶子节点要读自己的值，这里就直接从 context 里查。查不到就抛异常，比静默返回 false 更容易在排障时发现配置错误。

3.2 非终端表达式：用组合实现 AND、OR、NOT

接着是三个组合节点。先说 AND：

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(Map<String, Boolean> context) { return left.interpret(context) && right.interpret(context); } }

OR 和 NOT 也是一样的套路：

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(Map<String, Boolean> context) { return left.interpret(context) || right.interpret(context); } } public class NotExpression implements Expression { private final Expression inner; public NotExpression(Expression inner) { this.inner = inner; } @Override public boolean interpret(Map<String, Boolean> context) { return !inner.interpret(context); } }

看到没，每个类都极度简单，只有一个字段、一个构造方法、一个 interpret 方法。这就是解析器模式的核心风格：把复杂的语法规则拆解成一个个很小的类，每个类只负责一种规则的语义解释。

如果哪一天需要加一个 XOR 表达式，就再新建一个类，实现同样的接口，把解释逻辑写进去。老类完全不用碰。

3.3 Tokenizer：从字符流到 Token 序列

有了表达式类，还差最关键的“把字符串变成树”的环节。第一步是词法分析，我习惯先写一个 Tokenizer。

public enum TokenType { VARIABLE, AND, OR, NOT, LPAREN, RPAREN, EOF } public class Token { private final TokenType type; private final String text; public Token(TokenType type, String text) { this.type = type; this.text = text; } public TokenType type() { return type; } public String text() { return text; } } public class BooleanTokenizer { public List<Token> tokenize(String input) { List<Token> tokens = new ArrayList<>(); int i = 0; while (i < input.length()) { char c = input.charAt(i); if (Character.isWhitespace(c)) { i++; continue; } if (Character.isLetter(c)) { int start = i; while (i < input.length() && Character.isLetter(input.charAt(i))) { i++; } String word = input.substring(start, i); switch (word.toUpperCase()) { case "AND" -> tokens.add(new Token(TokenType.AND, word)); case "OR" -> tokens.add(new Token(TokenType.OR, word)); case "NOT" -> tokens.add(new Token(TokenType.NOT, word)); default -> tokens.add(new Token(TokenType.VARIABLE, word)); } } else if (c == '(') { tokens.add(new Token(TokenType.LPAREN, "(")); i++; } else if (c == ')') { tokens.add(new Token(TokenType.RPAREN, ")")); i++; } else { throw new IllegalArgumentException("无法识别的字符: " + c); } } tokens.add(new Token(TokenType.EOF, "")); return tokens; } }

Tokenizer 解决的是“单词边界”问题。字符串"A AND (B)"如果不切开，AND和A到底是一个变量名还是两个变量？切开之后，Parser 的工作就轻松很多，它不再关注空格，只看 Token 类型。

3.4 递归下降解析器：按文法逐层构建 AST

Tokenizer 切完 Token 之后，就轮到 Parser 上场。这里用的是递归下降（Recursive Descent）解析，核心原则是：文法的每一个产生式，对应一个解析函数。

public class BooleanParser { private final List<Token> tokens; private int pos; public BooleanParser(List<Token> tokens) { this.tokens = tokens; } public Expression parse() { Expression expr = parseOr(); if (peek().type() != TokenType.EOF) { throw new IllegalArgumentException("多余的内容: " + peek().text()); } return expr; } private Expression parseOr() { Expression left = parseAnd(); while (peek().type() == TokenType.OR) { next(); Expression right = parseAnd(); left = new OrExpression(left, right); } return left; } private Expression parseAnd() { Expression left = parseNot(); while (peek().type() == TokenType.AND) { next(); Expression right = parseNot(); left = new AndExpression(left, right); } return left; } private Expression parseNot() { if (peek().type() == TokenType.NOT) { next(); return new NotExpression(parseNot()); } return parsePrimary(); } private Expression parsePrimary() { Token token = next(); if (token.type() == TokenType.VARIABLE) { return new VariableExpression(token.text()); } if (token.type() == TokenType.LPAREN) { Expression expr = parseOr(); if (next().type() != TokenType.RPAREN) { throw new IllegalArgumentException("缺少右括号"); } return expr; } throw new IllegalArgumentException("意外的 Token: " + token.text()); } private Token peek() { return tokens.get(pos); } private Token next() { return tokens.get(pos++); } }

这段代码就是照着 BNF 硬翻译的。parseOr 管 OR，parseAnd 管 AND，parseNot 管 NOT，parsePrimary 管变量和括号。优先级通过函数调用层级天然实现：parseOr 调 parseAnd，所以 AND 会比 OR 先被约束在一起。

这里有一个很关键的工程点：文法里我没有写直接左递归。递归下降解析器最怕遇到expr := expr OP expr这种左递归文法，因为会无限递归下去。所以我在 BNF 里用*循环来表示同一层级的连续运算，在代码里用 while 循环处理。这是初学者最容易踩的坑。

3.5 一个可运行的最小闭环

现在把所有东西串起来。假设要解析规则：

A AND (B OR NOT C)

测试代码如下：

Map<String, Boolean> context = new HashMap<>(); context.put("A", true); context.put("B", false); context.put("C", false); String rule = "A AND (B OR NOT C)"; List<Token> tokens = new BooleanTokenizer().tokenize(rule); Expression expression = new BooleanParser(tokens).parse(); System.out.println(expression.interpret(context)); // 输出 true

算一下：NOT C 为 true，B OR true 为 true，A AND true 为 true，所以结果是 true。

为了在项目里排查问题方便，我还会给表达式类重写一个 toString 或专门的 treeString 方法。比如 AndExpression 的展示就是(AND left right)，NotExpression 是(NOT inner)。这样把规则解析成 AST 之后，可以先打印出来看看结构对不对，再做后续求值。

注意：打印 AST 是非常好用的调试习惯。字符串解析这东西，肉眼看到树长什么样，比猜来猜去高效得多。

3.6 扩展一：让规则支持比较运算

真实项目里没那么多纯布尔变量，常见的是score > 60 AND level >= 3。扩展方式其实很简单。

把接口改为更通用的形式：

public interface Expression { Object eval(Map<String, Object> context); }

或者保持一个返回 Object 的语义，让数值表达式返回数值，让比较表达式返回 Boolean，让逻辑表达式再组合 Boolean。比如 GreaterExpression：

public class GreaterExpression implements Expression { private final Expression left; private final Expression right; public GreaterExpression(Expression left, Expression right) { this.left = left; this.right = right; } @Override public Object eval(Map<String, Object> context) { double l = ((Number) left.eval(context)).doubleValue(); double r = ((Number) right.eval(context)).doubleValue(); return l > r; } }

再到 Tokenizer 里把>、>=、<、<=识别成对应的比较运算符，在 Parser 里加一层处理比较运算的 parseComparison。AndExpression 稍微调整一下，左右两边都当成 Object 求值，再统一强转成 Boolean 做逻辑运算。这样一套完整的可配置规则引擎就立起来了。

这种扩展方式，恰恰是解析器模式最值得称道的地方：对已有核心类改动极小，全部能力都是靠新增表达式类和新增解析分支堆出来的。

3.7 扩展二：数学表达式与优先级处理

再举一个经典例子：数学表达式计算器。比如3 + 5 * 2，如果按从左到右的朴素方式，会得到(3+5)*2=16，不对。必须让乘法先算，于是需要处理运算符优先级。

处理优先级有两个选择：继续用递归下降，或者用调度场算法（Shunting Yard）把中缀表达式转成后缀表达式，再构建 AST。我平时更常用后者，因为它绕开了递归下降里比较多见的左递归问题，思路很直白。

调度场算法的核心逻辑：

public List<Token> toPostfix(List<Token> infixTokens) { Deque<Token> ops = new ArrayDeque<>(); List<Token> output = new ArrayList<>(); for (Token token : infixTokens) { if (token.type == TokenType.NUM) { output.add(token); } else if (token.type == TokenType.LPAREN) { ops.push(token); } else if (token.type == TokenType.RPAREN) { while (!ops.isEmpty() && ops.peek().type != TokenType.LPAREN) { output.add(ops.pop()); } ops.pop(); } else if (isOperator(token.type)) { while (!ops.isEmpty() && precedence(ops.peek().type) >= precedence(token.type)) { output.add(ops.pop()); } ops.push(token); } } while (!ops.isEmpty()) { output.add(ops.pop()); } return output; }

顺序很清晰：数字直接进入输出；运算符先比较栈顶优先级，栈顶优先级不低于当前运算符，就先把栈顶弹出去；左括号直接压栈；右括号把栈顶弹出直到遇到左括号。

拿到后缀表达式比如3 5 2 * +后，再遍历一遍构建 AST：

Deque<ExprNode> stack = new ArrayDeque<>(); for (Token token : postfix) { if (token.type == TokenType.NUM) { stack.push(new NumberNode(Double.parseDouble(token.text()))); } else { ExprNode right = stack.pop(); ExprNode left = stack.pop(); stack.push(new BinaryNode(token.type, left, right)); } } ExprNode root = stack.pop();

最后每个节点都实现一个eval()方法，递归求值即可。这个例子的意义在于说明：解析器模式不止能做布尔规则，凡是“给一段文本，按文法求出一个值”的场景，它都能派上用场。四则运算、自定义脚本语言、简单的查询条件，底层都是同一套思路。

4. 实操中的常见问题与性能调优

4.1 并发环境下的 Context 陷阱

我踩过的第一个坑，是在表达式节点内部保存了中间结果。当时的 AndExpression 是这样的：

boolean leftResult = false; boolean rightResult = false;

两个线程同时跑同一套规则，结果互相覆盖，数据全乱了。后来改成无状态设计，所有中间值都放在调用栈里，也就是在 interpret 方法内部用局部变量接收子节点返回值，问题立刻消失。

这给了一个明确结论：表达式对象应当是一种“无状态策略”的形态。它只描述结构和行为，至于某个变量的值是多少，完全由调用时传入的 context 决定。如果非要让 context 在多个表达式之间共享，也要确保 context 本身是线程封闭的。最好是一次请求一个 context，请求结束就丢弃。

4.2 性能优化：缓存 AST 而不是重复解析

有人担心解释执行比硬编码慢，这个担心要拆开看。解析字符串、构建 AST 的耗时，和解释求值的耗时是两回事。如果一条规则被频繁使用，完全没有必要每次请求都重新 parse。把 AST 缓存起来，只重复执行 interpret/eval 就好。

实际操作中，我会把规则字符串作为 key，解析后的 Expression 对象作为 value，建一个并发安全的缓存。规则不变，AST 就不变。真正每时每刻发生的是对 AST 的递归求值。递归求值虽然比硬编码慢一些，但对绝大多数业务场景来说根本不是瓶颈，慢个几微秒到几十微秒，用户完全感知不到。

注意：如果缓存了 AST，一定要确保 AST 是无状态的。一旦你在某个表达式节点里保存了上一次的运行结果，缓存就会变成 bug 制造器。

4.3 错误处理：词法、语法、语义三个层面的提示

解析器模式的实践里，错误处理特别影响可用性。如果用户配置了一条错误规则，系统却只回一句“规则不合法”，那运营同学根本没法排查。我会把错误分成三个层面：

为了做到这一点，Token 里可以记录行号和列号，Parser 抛异常时把当前位置带出去。错误信息越具体，排查时间就越短。这算是我在实际项目里觉得性价比最高的一项投入。

4.4 极端情况：递归深度与表达式长度

递归下降解析和递归求值都会消耗调用栈。正常情况下表达式层级几十层没问题，但如果用户生成了一段非常长的规则字符串，嵌套括号几千层，递归深度就可能触顶。

我自己项目里遇到过类似情况，处理方式是加一层保护：在解析前限制输入字符串长度，比如不超过 2000 字符；解析时限制递归深度，超过 200 层直接抛错。对于业务配置型 DSL 来说，这个限制完全合理，规则复杂到“阈值都顶到天”的时候，问题的根源多半不是性能，而是规则本身已经失去可维护性。

5. 适用边界与替代方案

5.1 场景评估：什么情况下值得用解析器模式

不是所有需求都值得上解析器模式。我在项目里会做这么几个判断：

• 语法是否相对稳定？如果语法三天两头变，说明设计阶段还没收敛，先不要急着做通用解析引擎；
• 规则数量是否会持续增长？少于 10 条，用 if-else 可能更划算；
• 是否希望业务人员动态配置规则？如果是，字符串化的规则是基本前提，解析器模式几乎是必然选择；
• 团队是否愿意维护这套代码？解析器模式不是零成本，新增语法要新增表达式类和解析分支。

如果这四条的答案大多是“是”，那就可以放心做。如果答案大多是“否”，那就别为了用模式而用模式。

5.2 和组合模式、策略模式、访问者模式的分工

经常有人把解析器模式和几个邻近模式搞混。

组合模式解决的是“树形结构”的表达问题，解析器模式在组合模式之上增加了“解释执行”的语义。你可以理解成：组合模式提供了骨架，解析器模式让骨架动起来。

策略模式解决的是“算法族互换”的问题。比如规则引擎里解析策略可以根据需求替换，但这不是解析器模式的核心关注点。

访问者模式则经常和解析器模式配合使用。当 AST 的节点结构稳定，但对树的操作越来越多时，比如既要打印 AST，又要做类型检查，又要做求值，访问者模式可以把这些操作从节点类里剥离出来。遇到复杂 DSL 时，解析器模式 + 访问者模式是一对很常见的搭档。

5.3 什么时候该放弃手写解析器

手写解析器适合的是“小而精”的 DSL，比如十几个运算符、几十行文法。一旦语法规模大到像 SQL 或脚本语言那样，手写解析器的维护成本会急剧上升，这时候我不建议自己硬写。

判断信号其实很明确：当你发现自己开始在里面写类型推断、作用域管理、函数注册表的时候，就该考虑换更成熟的方案了。成熟的解析器生成工具能自动化处理词法、语法、语法树生成，社区生态也完善。自己做语言设计的成本，远比你想象中高。

但反过来说，像布尔规则、四则运算、简单查询条件这种体量，手写完全可控。这也是为什么我仍然推荐大家认真掌握解析器模式——它能把“小 DSL”这件事做得优雅又经济。

6. 写到最后：一点个人体会和建议

6.1 我的踩坑记录

如果让我总结自己最值钱的一条教训，那就是：写解析器模式之前，一定要先逼自己把 BNF 写出来。没有 BNF 就动手写 Parser，大概率会在优先级、括号、左递归这些地方反复返工。我最早做数学表达式计算器时就是直接写代码，结果优先级处理出错，改来改去浪费了一晚上。后来老老实实先把文法写清楚，代码反而一次性通过。

另一个坑是“过度封装”。我见过有人给规则引擎套了层层抽象，一个表达式接口下面七八个抽象类，美其名曰“为了扩展性”。结果真正的语法还没支持几个，代码已经没人愿意维护了。解析器模式的优雅在于简单，不在于复杂。一个接口，几个叶子节点，几个组合节点，一个 Parser，足够了。

6.2 给初学者的练习路径

想彻底掌握解析器模式，我建议按这个顺序练：

1. 先写一个布尔表达式解析器，支持 AND、OR、NOT、括号、变量；
2. 再加比较运算，比如大于、小于、等于；
3. 再做数学表达式计算器，体验优先级和调度场算法；
4. 最后尝试做一个小的自定义 DSL，比如告警规则、权限策略、工作流条件。

每一步都跑通，你就会发现，所谓设计模式，本质是前人把一类常见问题的解法沉淀成结构化的经验。解析器模式尤其如此——它的边界清晰、角色稳定、场景明确，一旦掌握，很多“配置化”“规则引擎”“DSL”类需求都可以轻松接住。别把它想得太高大上，它就是一门“把文本变成树，再把树变成结果”的手艺。这门手艺，值得每个做后端和做业务系统的人花时间练一遍。