解释器模式是将业务规则从代码中解耦，通过轻量级DSL让非技术人员可读、可改、可验；其核心是用对象映射语义、组合表达逻辑、递归执行判断，涵盖语法设计、对象建模、手写解析、执行扩展四部分。
解释器模式不是为了造轮子，而是把规则从代码里“请出来”，让运营、测试甚至产品能看懂、能改、能验。它不追求通用语言的完备性，而专注在“够用、易读、可插拔”——一套轻量级语法糖的核心，其实是用对象映射语义，用组合表达逻辑，用递归执行判断。
语法设计：从自然描述到结构化表达
先别急着写类，先写出人能读的规则样例：
- 订单金额 > 100 且 用户等级 == "VIP"
- 新用户 || (订单商品数 >= 5 && 有优惠券)
- 下单时间.between("2026-01-01", "2026-12-31")
这些不是字符串拼接，而是语法糖的“输入界面”。关键在于识别三类元素：
-
终结符：字面量（
"VIP"）、变量（订单金额）、常量（5）、函数名（between） -
操作符：比较（
>、==）、逻辑（&&、||）、调用（.） - 结构词：括号控制优先级、引号界定字符串、空格分隔token
对象建模：让每个语法单元变成一个可解释的对象
不用强行套用“抽象表达式→终结符/非终结符”的教科书分层，而是按语义职责拆解：
-
VariableRef：包装字段名，如
new VariableRef("订单金额")，执行时从上下文取值 -
Literal：封装字面值，支持 String/Number/Boolean/Date，如
new Literal("VIP") -
BinaryOp：统一处理二元操作，构造时传入左、右表达式 + 操作符枚举（
GT、EQUALS），interpret 时分发判断 -
LogicalOp：专管
&&/||，支持短路求值（左为 false 且是&&，则跳过右表达式） -
FunctionCall：如
between，持有函数名、参数列表（也是 Expression），执行时查注册表找对应 Java 方法
这样建模后，订单金额 > 100 就对应一个 BinaryOp(VariableRef("订单金额"), Literal(100), GT) 实例——语义清晰，无歧义，也便于单元测试。
解析实现：手写递归下降，不依赖外部工具
轻量级 ≠ 简陋。对简单 DSL，手写解析器比引入 ANTLR 更可控、更易调试：
- 第一步：Tokenizer 把输入切分成 token 流（跳过空格，识别引号内字符串、数字、操作符等）
- 第二步：Parser 基于优先级做递归下降，例如：
– 先 parseOrExpression（处理||）
– 内部调用 parseAndExpression（处理&&）
– 再调用 parseComparison（处理>、==）
– 最终落到 parsePrimary（变量、字面量、括号表达式） - 第三步：每层返回 Expression 对象，最终构建成一颗小 AST，而非字符串或 Map
好处是：语法变更时，只需调整 Parser 的某一层逻辑；新增函数只需注册方法，无需动语法树节点。
执行与扩展：上下文即数据源，注册即能力中心
解释器真正运行时，只依赖一个 Context 对象：
- 它不一定是 Map，可以是带 getter 的 POJO（如
OrderContext），VariableRef.interpret()直接反射调用getOrderAmount() - 函数能力通过
FunctionRegistry统一管理：registry.register("between", (args) -> {...})，规则里出现.between(...)就自动绑定 - 支持热重载：规则文本变更后，重新 tokenize → parse → interpret，无需重启服务
这种设计下，加一条“仅限工作日下单”的规则，只需新增一个 isWeekday() 函数并注册，规则写成 下单时间.isWeekday() 即可生效。
