如果你所在的项目组也经历过这样的需求按钮的显示条件不在代码里而在运营后端的动态配置里订单的折扣规则不写在 if-else 里而是随时可能被产品经理调整——那你应该会对这篇分享有共鸣。我们组前段时间负责一个跨平台后台系统里面十几个业务模块都堆着大量重复的条件判断代码每个人都在用自己的方式写“规则”。后来我们统一收敛到一个内部代号叫rea的轻量级表达式引擎上从设计、开发到业务全量接入前后花了大约三周。这篇文章不是给某个库做推广而是把我们实现 rea 时的取舍、踩过的坑、以及最终落地到权限控制和动态表单联动里的完整过程写出来。如果你正在做规则引擎、低代码表单联动、数据筛选配置这类需求或者只是好奇“表达式引擎到底是怎么被写出来的”这篇内容应该能给你一些可复用的思路。1. 硬编码、重型引擎、运行时字符串三个方向都试过以后才轮到 rea在动手写 rea 之前我们把市面上能想到的方案都摆到桌面上过了一遍。不是没走弯路是走了好几条弯路之后才确定它不该被做成一个通用的规则引擎也不该继续用拼接字符串的方式凑合。1.1 硬编码条件判断业务一改就要发版先说说最开始的情况。某个后台页面的操作按钮要不要展示逻辑是这样的if (user.role admin || (user.level 3 dept.category ops)) { showExportButton(); }单看这段代码没什么问题但它散落在十几个模块里规则还各不相同。等运营提出“高级会员且订单超过 1000 元也显示导出按钮”时我们得去代码里搜索所有相关的 if 分支逐个改动再走一次发版流程。页面多、分支多的时候很容易漏改而且不同模块之间口径会漂移——这边写level 3那边可能写level 2肉眼根本看不出来。硬编码最大的问题不是“能不能实现”而是“改不动”。规则是动态变化的代码却是静态的两者天然不匹配。1.2 重型规则引擎能力过剩带来的新问题既然规则要动态改我们第一反应是引入成熟的规则引擎。但这种方案在落地时很快暴露问题它的功能确实强大有事实库、规则冲突处理、复杂的匹配算法但我们需要的大部分场景只是“某个字段满足条件之后让某个按钮可见或者让某个字段单元格联动变色”。为了这种场景去维护一套独立的规则服务带来的学习成本和部署成本都不低。前端同学要看懂规则文件都要花很大力气更不用说让运营人员去配置。这个方向被我们否掉是因为明显“杀鸡用了牛刀”能力过剩本身也是一种负担。1.3 eval / new Function拼接字符串的隐患当时也有同事提过用 eval 或动态创建函数来跑规则因为这种方式最直接把字符串拼成一段 JS 代码然后交给运行时执行。比如这样的思路const rule user.role admin order.amount 1000; const fn new Function(user, order, return rule ;);跑起来确实很爽但隐患也很明显。规则字符串如果来自运营配置等于直接把一段可执行代码的入口交给了外部输入即便做了白名单过滤也很难在拼字符串的过程中保证作用域里没有危险对象被访问到。还有一个被低估的问题是性能规则每次执行都要重新编译一次代码虽然在低并发场景下体感不强烈但一旦进入请求量稍高的服务解析成本会被放大。另外 eval 体系的调试体验也很差报错信息经常是“代码上下文不可用”出了问题很难定位是哪一段规则写的。这种方案作为临时脚本还行作为长期基础设施不合适。1代理商 rea 的目标边界一个“够用”的表达式子集经过这几轮对比我们最终决定自己造一个轮子。但需要强调的是我们并没有打算做成“一门语言”只是做一个有限表达式子集支持字段读取、数值比较、字符串匹配、逻辑组合、三元表达式以及少量内置函数。它不提供循环、不提供赋值、不提供任意函数调用所有可访问的字段和函数都必须显式注册。这个边界是刻意划出来的。规则配置需要的是“描述一个条件”而不是“执行一段逻辑”。把边界收窄之后安全性和可控性会好很多这也是 rea 能把代码量控制在很小规模的根本原因。2. 三周时间把 rea 拆成三段管道词法、AST、栈式执行rea 的内部结构和大多数解释器一样是一条三段式管道字符串先经过词法分析变成 token再由语法分析生成抽象语法树最后经过编译生成栈式指令流并执行。听起来枯燥但每一段都有值得展开的细节。2.1 词法分析表达式是怎么被切成 token 的词法分析的核心任务就是把一个字符串切成有意义的“词片”也就是 token。举个例子下面这条规则user.level 3 order.amount 100它会被切成这样一组 tokenuser.level - IDENT - OP_GE 3 - NUMBER - OP_AND order.amount - IDENT - OP_GT 100 - NUMBER这里要特别注意两个地方。第一user.level和order.amount这类带点的字段路径要在词法阶段就作为一个整体识别出来不能拆成user、.、level三段再处理否则后面的解析会绕远路。第二字符串常量的转义必须在这一步完成。比如配置里写了it\s我们需要在切 token 的时候把转义字符解析成真正的字符串内容而不是留到执行阶段再去处理。我们用的实现方式是按字符逐位扫描配合一个简单的状态机当前处于普通字符、字符串内、数字内、运算符内等不同状态决定下一个字符应该归并到哪个 token。这种写法比单纯用正则表达式匹配更可靠因为它天然处理了“字符串里包含运算符”这类边界情况——正则很难优雅地区分到底是一个运算符还是一段字符串里的内容。2.2 Pratt 解析让运算符优先级不再靠砍树词法只是把字符串切成小块真正决定运算顺序的是语法分析。这里我们用的是Pratt 解析也就是优先级攀爬算法。它通过给每个运算符绑定一个“优先级数字”来控制递归下降的深度比手写一堆嵌套函数更干净。比如user.level 3 order.amount 100表达式中包含、、三种运算符它们优先级从低到高排列是最低和中等 -更高* /更高。Pratt 解析器会根据当前遇到的运算符优先级决定是继续递归读取右操作数还是把已经构建好的节点向上返回。这段表达式最终会生成一棵这样的 AST{ type: LogicalExpression, operator: , left: { type: BinaryExpression, operator: , left: { type: FieldAccess, name: user.level }, right: { type: Literal, value: 3 } }, right: { type: BinaryExpression, operator: , left: { type: FieldAccess, name: order.amount }, right: { type: Literal, value: 100 } } }有了 AST 之后后续的所有优化和执行都有了稳定的中间表示。2.3 栈式执行器指令流比深度递归更可控AST 可以直接用递归方式求值这也是很多小项目会采用的做法。但 rea 选择了先编译成指令流再用一个栈式执行器来跑。原因有两个一是递归求值容易受到调用栈深度限制表达式嵌套很深时会直接栈溢出二是把 AST 编译成指令流之后可以顺手做掉很多优化比如把常量运算提前结算、把逻辑表达式的短路编译为跳转指令。一个简单表达式a b * 2会编译成类似这样的一组指令LOAD a LOAD b LOAD 2 MUL ADD RETURN执行器维护一个操作数栈遇到 LOAD 就把值压栈遇到 MUL 和 ADD 就从栈顶弹出两个值运算后再把结果压回去最终 RETURN 时栈顶就是最终结果。整个逻辑很接近我们大学时学的虚拟机原理并不复杂但胜在每一步的状态都可观测出问题时很好调试。2.4 类型感知就为了避免 1 1 这种乌龙绝大多数表达式引擎最容易翻车的地方是类型比较。JavaScript 本身的会把1和1当成相等这在业务规则里非常危险某条规则判断order.status 1如果上游传入的状态字段是字符串1直观上也“通过了”但类型语义是模糊的。rea 的做法是不提供宽松比较语义。它在内部把比较运算统一处理成严格比较数字和数字比较、字符串和字符串比较布尔值只能和布尔值比较。如果两边类型不一致直接抛出一个类型错误让规则配置者在开发环境就能发现字段类型不匹配而不是把问题带到线上。同时我们还处理了三值逻辑当字段取值为null或undefined时比较结果应当稳定为false而不是抛异常。比如规则里写了user.role admin但用户对象里面根本没有role这个字段这条规则应该做“不成立”处理不能让整个求值过程崩掉。3. 从 Hello World 到业务落地的完整接入过程设计阶段聊完了接下来看接入实操。从跑通第一个表达式到真正在业务里承担权限判断这里有一条很明确的上手路径。3.1 最小接入路径三步跑通第一个表达式rea 对外暴露的核心是一个引擎对象使用方式非常直接import { createEngine, builtin } from rea; const engine createEngine({ functions: { ...builtin }, }); const ctx { a: 1, b: 3 }; const result engine.evaluate(a b * 2, ctx); console.log(result); // 7内部流程是先对表达式做词法和语法分析生成 AST再编译成指令流最后带着上下文执行。每一步都有缓存同一个表达式如果重复执行会走缓存路径避免反复解析的开销。这里有个容易忽略的细节evaluate方法接收的上下文对象应该只包含表达式可能访问到的最小字段集合而不是把整个请求体、整个用户对象直接塞进去。否则大对象的遍历和闭包持有都会带来额外的内存和性能问题这一点在后面的踩坑章节会具体展开。3.2 上下文怎么设计显式声明字段而不是传整个对象我们在设计 API 的时候特意提供了一个字段白名单机制const engine createEngine({ fields: [user.role, user.level, order.amount], functions: { has: (arr, v) arr.includes(v) }, }); const visible engine.evaluate( user.role admin || (user.level 3 order.amount 1000), { user: { role: admin, level: 3 }, order: { amount: 2000 }, } );fields声明了表达式允许读取的字段路径。执行时rea 会按这个白名单从上下文里取值而不是把整个对象直接暴露给表达式。这样做有两个收益。第一是安全。规则配置者只能访问声明过的字段没法通过某个对象的长链路径去探测额外数据。第二是性能。执行器只需要针对性地读取几个字段不需要为了评估一个表达式把整个用户对象序列化或者深度复制一遍。这种设计的代价是每次接入新业务都要把用到的字段显式声明一遍稍微繁琐一些。但当我们同时维护十几个业务模块时这种繁琐反而变成了优点——每个模块能用哪些字段一条配置一目了然。3.3 自定义函数注册与副作用隔离字段之外表达式还需要函数调用能力。rea 支持两种函数一种是内置的通用函数比如in、startsWith、dateBefore另一种是业务方注册的自定义函数。const engine createEngine({ functions: { in: (value, list) list.includes(value), dateBefore: (left, right) new Date(left).getTime() new Date(right).getTime(), acl: (user, permission) user.permissions.includes(permission), }, }); const allowed engine.evaluate( acl(user, export) !user.disabled, { user: { permissions: [export], disabled: false } } );函数注册需要注意一个原则注册进来的函数必须是无副作用的。也就是说函数不能修改外部状态、不能发起网络请求、不能写入缓存。我们把这句话写在了代码评审的 checklist 里任何带副作用的函数都不允许被注册进 rea。原因很简单规则表达式本身应该是一个纯函数输入相同上下文任何时候求值都应该得到相同结果一旦允许规则里的函数偷偷改变外部状态排查线上问题时会非常痛苦。3.4 权限规则实战一个覆盖动态字段、函数、逻辑组合的完整例子权限控制是我们接入 rea 最典型的场景。所有按钮的显示逻辑不再是代码里的 if 分支而是一张规则表规则 ID目标动作表达式btn_export显示导出按钮user.role admin或user.level 3 dept.name 运营部btn_import显示导入按钮acl(user, import) !user.disabledrow_highlight订单行高亮order.amount 5000 order.status in (待支付, 待发货)接入代码大致是这样的const ruleMap new Map( rules.map((rule) [rule.id, rule.expr]) ); function canShow(ruleId: string, bizContext: Recordstring, any) { const expr ruleMap.get(ruleId); if (!expr) return false; return engine.evaluate(expr, bizContext) true; }这里我们用的是“白名单”策略默认不显示按钮只有规则表达式的求值结果严格等于true时才显示。这样即使规则配置写错也不会出现权限意外放开的情况最多就是按钮漏显示容易通过测试发现。动态表单联动也走了类似的套路。比如支付方式和配送方式之间的联动规则field.payment 货到付款 ? field.deliveryMode in (快递, 自提) : field.deliveryMode 自提规则配置改变之后不需要重新发布代码运营在配置后台保存新表达式下一次请求进入业务系统时就会自动生效。这也是 rea 对业务最大的价值把“规则变更”从“代码变更”中彻底剥离出来。4. 排障实录三个把测试逼疯的问题和最终修法任何引擎从能跑到能稳定跑中间都隔着不少坑。这里分享三个我们真实踩过、也花了不少时间排查的问题。它们都是那种“不看源码根本猜不到原因”的类型希望你能绕过。4.1 短路求值居然先执行了右侧函数指令顺序的锅第一次线上事故来自逻辑运算的短路。规则是这样的false computeCost(order) 100按照常规理解右边的computeCost(order)压根不应该执行。但我们第一次实现时图省事把两个操作数先分别压栈再执行 AND 指令。结果就是右边表达式中的函数调用在指令流里位于 AND 判断之前函数已经被执行了。一旦computeCost内部遇到异常整条规则直接报错排查日志时发现这条规则左侧已经是false那它凭什么还去调用成本函数定位到问题后我们修改了编译逻辑逻辑表达式不再简单压栈而是编译成条件跳转指令。LOAD false JMPF L_END // 如果左侧为 false直接跳到 END右侧不求值 LOAD order LOAD cost CALL 1 LOAD 100 GT L_END: RETURN从这以后短路语义才真正正确。这个坑告诉我们表达式引擎的执行顺序不能只看“最后的结果对不对”还要关注求值和函数调用发生的时机。4.2 宽松比较带来的幽灵结果类型转换规则被重写第二个问题比较隐蔽。某个上线了一周的规则突然在客户环境上失灵订单状态明明是1规则里写的是order.status 1理论上应该匹配但因为生产环境的数据源给状态字段赋值时带上了引号而 rea 内部一开始为了手感顺滑把处理成了宽松比较字符串1和数字1被当成相等规则通过了。问题是这种“通过”是偶然的。后来客户后台把状态枚举从1改成2配置同步更新成了order.status 2但有个上游字段的值还是字符串2宽松比较仍然能通过。直到某一天上游系统调整了类型状态字段变成了数字2规则反而又匹配不上了。这类问题最麻烦的地方在于它不是稳定复现的而是依赖输入数据的类型。我们最终决定重写比较逻辑统一走严格比较并增加类型错误提示。修复后不仅这个规则的问题解决了规则配置阶段就能发现“字段类型写错”的情况测试同学再也不用靠猜。下表是修复前后的行为对比规则写法上下文字段实际类型修复前结果修复后结果order.status 1status 为数字 1truetrueorder.status 1status 为字符串1true抛类型错误order.flag trueflag 为数字 1true抛类型错误user.name nullname 为 undefinedfalsefalse空值统一为 false4.3 执行上下文复用后内存不释放对象池和生命周期管理第三个问题来自性能优化本身。我们为了让高并发场景下的重复求值更快做了一层对象池把解析好的 AST 和执行器实例都缓存起来。但跑了一段时间之后服务内存持续上涨heap snapshot 一看发现大量上下文字段还被闭包引用着根本释放不掉。根因是缓存里保存了执行器的函数闭包而闭包里又引用了上一次求值传入的上下文对象导致整个业务大对象一直留在内存里。表达式执行完了上下文却不该被继续持有。修法是把执行器的生命周期拆分成两块解析和编译结果可以全局缓存但每次执行时必须创建新的执行帧执行结束后立即解除对上下文的引用。这样既保留了缓存带来的性能优势又避免了无谓的内存驻留。实测修复后同样的并发压力下内存曲线平稳了很多。5. 如果你也想自己实现一个表达式引擎从最小版本开始最后说点方法论层面的东西。如果你看完这篇也想动手实现一个类似的表达式引擎我不建议一上来就照着 rea 的全部功能做。大多数人更适合一步一个脚印按功能迭代。5.1 第一周目标只支持四则运算、括号和变量第一周的目标可以定得很小让表达式(a 1) * 2能正确求值。这时候你需要的组件是一个能切出数字、运算符、括号和变量的词法分析器一个能生成简单 AST 的递归下降解析器一个直接递归求值的执行函数。这个版本不需要函数调用、不需要字符串、不需要逻辑运算甚至不需要严格的报错机制。它存在的意义是让你把整条管道跑通建立对“词法 - 语法 - 求值”这条链路的具象认知。第一周的代码量大概在 400 行左右强烈建议不依赖任何第三方 AST 库自己写。这个过程会把解析器的很多细节刻进你的直觉里之后再换成高级方案会顺手得多。5.2 第二周目标函数调用、比较逻辑和短路支持第二周再逐步增加能力先加字符串常量和比较运算符再加、||、!最后加自定义函数注册。加逻辑运算时记得一开始就直接做成短路跳转别走我们最开始“两个操作数都求值再合并”的弯路。加函数的时候顺手把函数的纯函数约束设计进去规则函数不允许写外部状态这比以后补约束简单得多。这周结束的时候你应该已经能跑通类似这样的表达式user.level 3 has(user.tags, vip) order.amount 1000能跑到这一步就已经具备解决真实业务问题的能力了。我们团队内部落地大部分权限规则时用到的能力就停在这一层。5.3 一定要补的测试与基准单测、模糊测试、性能回归表达式引擎这种组件表面上看起来很简单但边界情况特别多非常需要测试来兜底。我们最终给 rea 配了三层测试。第一层是常规单测覆盖每个运算符的正常路径和异常路径比如除以零、类型不匹配、字段越权访问。第二层是模糊测试随机生成表达式和上下文在一个完全隔离的安全环境里用参考实现跑一遍对比结果是否一致。第三层是性能基准测试把每个规则表达式预先编译缓存后测量单次求值的耗时和内存分配量防止后续优化反而拉低性能。性能数字很难跨环境对比但可以说一个量级在普通的开发机环境下预热完成后的简单比较表达式单次求值耗时在微秒级这对大多数后台权限判断场景已经足够了。关键是性能曲线要稳定不能出现“规则复杂一点就慢一个数量级”的抖动。5.4 我的一点体会项目做完之后我最大的体会是表达式引擎的难点不在于“让表达式跑起来”而在于“划定边界并且守住边界”——不让规则干它不该干的事不让类型在宽松比较里含糊过去不让执行上下文泄露到缓存里。这些边界问题往往是在做项目的第三周、第四周才暴露出来的而恰恰是它们决定了一个引擎能不能真正用到生产环境。另外别一上来就想着做图灵完备。规则配置场景里哪怕你支持的语法再少只要把比较、逻辑、函数调用和短路这四件事做扎实就已经能覆盖绝大多数动态化需求了。做得越“少”往往越稳定、越好用。这就是 rea 这个项目给我上的最重要一课。