使用解释器模式有哪些常见错误？
简化版
解释器模式常见错误包括：用它处理复杂语言、解析和执行混在一起、表达式类过多、缺少错误提示、忽略性能、表达式来自用户输入却不做安全限制。它适合小型 DSL，不适合无限扩展的复杂规则系统。
详细版
常见错误：
- 语法复杂却手写解释器。
- 所有规则堆在一个大类里。
- 表达式节点职责不清。
- 没有区分解析、校验、解释。
- Context 类型混乱。
- 错误提示不友好。
- 没有限制表达式复杂度，可能被恶意输入拖垮。
- 用户表达式可调用危险函数。
解释器模式要控制边界：语法小、规则清晰、执行可控，才适合。
完整版教学
一、处理复杂语言
解释器模式最怕需求不断膨胀。一开始只是 A AND B，后来加括号、优先级、函数、数组、对象、作用域、类型推断。
如果没有成熟解析架构，代码会迅速失控。
二、解析和解释混在一起
有些实现一边读字符串一边执行逻辑。这样很难做语法检查、错误定位和表达式复用。
更好的方式是先解析成表达式树，再解释执行。解析失败就给出明确错误，解释阶段只处理语义。
三、安全和性能
表达式来自用户输入时，要限制长度、递归深度、函数白名单和执行时间。否则恶意表达式可能导致 CPU 打满或访问不该访问的数据。
Context 也不要暴露敏感对象，避免规则表达式越权读取系统信息。
四、常见误区与工程判断
不要把解释器模式当成低成本规则平台。规则平台还需要版本、灰度、审核、回滚、调试、监控。
工程中如果规则会被大量业务人员配置，工具链和可观测性比模式本身更重要。
五、解释器模式最怕被滥用成手写语言引擎
解释器模式常见错误之一，是把复杂语法也强行用简单类结构手写。语法一旦包含优先级、括号、函数调用、类型系统、错误恢复、性能优化，复杂度会迅速上升。如果团队没有意识到这些成本，最后会造出一个难维护的半成品语言引擎。
第二个错误是忽略解析和校验。Expression 类只负责执行规则，但输入字符串是否合法、变量是否存在、类型是否匹配，都需要在解释前或解释过程中处理。否则用户配置一条错误规则，系统只会在运行时抛出模糊异常。
第三个错误是每次执行都重新解析。规则如果频繁执行，应把字符串解析成表达式树后缓存起来，运行时只替换 Context。这样既提升性能，也能把语法错误提前暴露，而不是在高频请求路径里反复解析。
面试时可以主动补一个安全点：如果表达式来自用户输入，要防止把解释器做成任意代码执行入口。可配置规则应该限制语法能力、限制函数白名单、控制执行时间，避免出现死循环、资源耗尽或越权访问上下文数据。
还有一个维护性问题：表达式类越来越多时，要给每类节点配套单元测试，尤其测试优先级、短路逻辑、空值和类型错误。解释器模式表面是对象组合，实际是在实现一套可执行规则系统，测试覆盖不能太薄。
六、用工程约束检验答案
三个高风险错误是：用 split 代替解析器、让 AST 节点直接执行任意服务、不给递归深度设上限。一个含 10000 层括号的输入可能造成栈溢出；未设白名单的函数调用则可能把 DSL 变成攻击入口。
| 检查项 | 核心判断 | 工程含义 |
|---|---|---|
| 解析与解释混合 | 优先级和报错混乱 | Lexer/Parser/Evaluator 分层 |
| 能力无限开放 | 注入与越权 | 变量和函数白名单 |
| 无资源限制 | 深递归或超时 | 节点数、深度、时间预算 |
把关键关系压缩成一条可复述的路径：
输入长度检查
token 与语法校验
AST 节点数/深度限制
受限 Context 中求值解释器处理的是不可信输入时，正确语法只是起点，还必须限制它能看什么、能调用什么、能运行多久。
落地前可以再按下面 3 步复核：
- 先说明“解析与解释混合”的核心机制：优先级和报错混乱；再交代边界：Lexer/Parser/Evaluator 分层。
- 接着分析“能力无限开放”：注入与越权；不能遗漏对应代价或结果：变量和函数白名单。
- 最后用“无资源限制”检查方案：深递归或超时；验收时确认节点数、深度、时间预算。
这三项构成完整判断链：先讲清解析与解释混合，再说明能力无限开放，最后用无资源限制检验实现是否越界。
面试中若能给出违反“节点数、深度、时间预算”的反例，再说明修正办法，答案就从模式定义落到了可验证的工程决策。
七、常见误区与追问
- 误区：只看到“解析与解释混合”就认为方案成立。 必须同时说明核心机制“优先级和报错混乱”和工程边界“Lexer/Parser/Evaluator 分层”。
- 误区：把“能力无限开放”当成无条件结论。 只有在“注入与越权”成立时，才能据此讨论“变量和函数白名单”。
- 追问：正则能代替 Parser 吗？ 简单固定格式可以，嵌套递归文法通常不适合仅靠正则。
- 追问：catch Exception 返回 false 好吗？ 不好，会混淆语法错误、变量缺失和合法 false。
- 追问：为什么避免节点内查数据库？ 会产生 N+1 I/O、不可预测延迟和权限风险。
- 追问：递归一定不能用吗？ 可以，但要限制深度；超深结构可改显式栈。
- 追问：怎样防函数注入？ 只注册允许的纯函数，并校验参数类型、次数和执行预算。
八、加强记忆
记忆时抓住这条主线：解释器模式适合小语法，不适合复杂语言；解析、校验、解释要分层；用户输入表达式必须做安全限制；类爆炸和性能问题是主要风险。面试回答先给出模式意图，再用调用链或数据流说明角色协作，最后主动交代适用边界与工程代价。