解释器模式通过将语法规则映射为类，构建抽象语法树（AST）来解析和执行领域语言。每个节点实现interpret方法，递归解释表达式，适用于结构简单的DSL，如布尔条件"username='admin' AND loginCount>3"。通过上下文（context）传递运行时变量，支持动态求值。模式需配合词法和语法分析器将字符串转为AST，适合规则引擎等场景，但复杂语法可结合脚本引擎优化。关键在于语法的对象化建模与递归执行机制。
解释器模式通过为语言中的每条语法规则定义对应的类，把语法解析和执行过程封装起来，从而实现对特定领域语言（DSL）的处理。它适合结构简单、语法规则明确的领域语言，让非程序员也能用接近自然语言的方式描述逻辑。
语法如何被分解与建模
在解释器模式中，每一条语法规则都映射为一个类。整个语言的结构被表示成一棵抽象语法树（AST），树的每个节点代表一个语义单元。
例如，一个简单的数学表达式 DSL 如 "3 + 5"，其语法规则可能包括：
- 表达式（Expression）：可以是数字或操作
- 数字（Number）：表示常量值
- 加法操作（Addition）：包含左操作数和右操作数
每个节点都实现一个 interpret(context) 方法，负责解释自身并返回结果。解释过程从根节点开始递归执行。
如何实现一个简单的 DSL 解释器
以布尔条件 DSL 为例，比如 "username = 'admin' AND loginCount > 3"，我们可以这样设计：
- 定义抽象表达式接口，包含 interpret 方法
- 实现具体节点类：VariableExpression、ConstantExpression、EqualsExpression、GreaterThanExpression、AndExpression 等
- 解析字符串时，将条件拆解并构造成树结构
- 调用根节点的 interpret 方法，传入当前上下文（如变量值映射）
比如 AndExpression 的 interpret 会先调用左子节点和右子节点的 interpret，再对两个布尔结果做逻辑与操作。
上下文与变量管理
DSL 通常需要访问运行时数据，比如用户信息、系统状态等。解释器通过 context 参数传递这些信息。
context 一般是一个 map 或专用对象，存储变量名到值的映射。在 interpret 过程中，VariableExpression 节点会根据名称从 context 中查找实际值。
这种方式让 DSL 表达式能动态适应不同输入，增强灵活性。
语法解析的局限与应对
解释器模式本身不处理字符串到语法树的解析，它只负责执行已构建的树。因此需要配合词法分析器（lexer）和语法分析器（parser）使用。
常见做法：
- 用正则表达式或状态机做词法分析，切分 token
- 用递归下降法或工具（如 ANTLR）生成语法树
- 将生成的节点转换为解释器模式中的表达式对象
对于复杂语法，解释器模式可能变得笨重。此时可考虑结合脚本引擎（如 Lua、JavaScript）或编译型 DSL。
基本上就这些。解释器模式让 DSL 的语义清晰可扩展，适合规则引擎、配置逻辑、简单脚本等场景，关键是把语法结构转化为对象模型，再通过递归解释执行。不复杂但容易忽略细节，比如上下文传递和异常处理。
