基于KOV与依赖图的联动规则组件设计与实现

做中后台表单和流程配置的同学应该都有过这种经历业务方跑过来说“这个字段选了 A下面那几个就不要再填了选了 B金额输入框必须出现而且默认带出上一步的值”。你听完觉得不难随手写了几个if结果第二周规则加到二十条字段开始互相打架页面一刷新顺序不一样隐藏的字段还在提交校验里报错。这篇就是我围绕联动规则组件做的一轮 KOV 场景梳理和技术方案沉淀把散落在各个业务里的联动需求收拢成一套可配置、可校验、可回放的机制。KOV 是 Key-Operator-Value 的缩写也就是“哪个字段、做什么判断、和什么值比”这个三元组。它是联动规则的原子单位把一句话规则拆成机器能算、人能看懂的结构。联动规则组件要干的事情很明确业务侧用 KOV 把条件拼出来运行时由组件算出每个字段该显示还是隐藏、禁用还是可编辑、必填还是选填、值该不该被清掉、下拉选项要不要按前置条件过滤。适合谁来读正在做表单引擎、流程设计器、低代码配置面板的前端同学以及被“字段联动”这四个字坑过一次、不想被坑第二次的人。下面我按场景梳理、结构设计、核心实现、配置态设计、问题排查的顺序讲中间会贴结构定义和关键算法能直接抄的部分我都标出来了。1. 先把“联动”这件事拆干净KOV 到底覆盖哪些场景在做技术方案之前我踩过最大的坑就是一上来就写代码结果写到一半发现“联动”这个词下面藏了五六种完全不同的东西它们的数据结构、求值时机、渲染影响都不一样。所以第一件事是把场景盘清楚这也决定了后面组件的抽象边界在哪里。1.1 KOV 三元组的本质把一句话规则变成可计算的数据业务说“当订单类型为预付费且金额大于一万时审批人字段必填”这句话里其实有两个 KOV订单类型 eq 预付费、金额 gt 10000中间用“且”连接然后接一个动作“审批人 required”。所以一条完整规则由三部分组成条件树Condition、动作列表Action、优先级与开关Meta。KOV 描述的是条件树里最末端的叶子节点。为什么一定要拆成三段而不是直接存一个表达式字符串我做过对比。存表达式字符串的好处是表达力强坏处是配置态没法做可视化回显用户改一个值你得解析字符串再拼回去校验态没法做字段级定位报错只能报“表达式非法”安全上更麻烦等于把一段可执行代码交给业务配置人员。而 KOV 结构化之后每个字段都能被单独校验、单独翻译成自然语言、单独做权限控制。代价是表达力受限需要通过组合与/或/非、嵌套组来补。实测下来九成以上的业务联动用 KOV 加两层嵌套就够用了剩下那一成我会留一个“高级表达式”后门但要求走审批。三元组里最容易出问题的是 Operator 这一端。很多人一开始只做eq和ne跑到第三个业务就顶不住了。我现在的做法是把操作符做成注册表按字段类型分组挂载数字类型挂gt/gte/lt/lte/between字符串挂contains/startsWith枚举挂in/notIn日期挂区间比较集合类型挂hasAny/hasAll。操作符不是写死的 switch而是带元信息的一个对象需要几个值、值从哪个字段类型来、是否支持空值。这样配置面板可以按字段类型自动渲染出正确的操作符下拉运行时也只需要查表调用。还有一点容易被忽略KOV 的 Value 端可能不是一个常量。真实场景里大量存在“A 字段等于 B 字段”这样的比较或者“金额大于上一步的预算”。所以 Value 端要支持两种形态字面量Literal和引用Reference。字面量走类型转换引用走路径寻址。这个设计在第一天就要留好口子否则后面改起来会波及整个求值链路。1.2 六类高频联动场景盘点我把过去几个项目里出现过的联动需求做了归类大致落在下面六类里。这张表是我跟产品对齐需求时的底稿基本上一张表就能说清楚组件的能力边界。场景类别典型描述影响目标求值时机实现复杂度显隐联动选了“其他”才出现备注框字段可见性依赖值变更时低禁用联动审批通过后所有字段置灰字段可编辑性状态/依赖值变更低必填联动金额超阈值时审批人必填校验规则依赖值变更时中赋值联动选了城市自动带出区域编码字段值依赖值变更时中选项联动二级分类选项按一级分类过滤选项数据源依赖值变更 异步高结构联动选“多主体”才展示子表单区块DOM 结构/子表单实例依赖值变更时高前四类是刚需几乎每个表单都有选项联动之所以复杂是因为它牵扯异步请求和竞态用户快速切换一级分类时慢回来的那个请求可能把新选项覆盖掉这个坑我在两个项目里都踩过后面会用请求序号来解决结构联动最麻烦因为它不只是改属性还要处理子表单的实例化、销毁和值回收一旦子表单被隐藏里面已经填的数据是保留还是清空必须跟业务明确约定不能自己拍脑袋。这里要说一个容易漏掉的边界联动的触发源不只是用户输入。初始化赋值、接口回填、草稿恢复、跨步骤跳转这些都会让字段值发生变化进而触发规则。如果只在onChange里跑规则那接口回填的数据就不会触发联动页面一进来就是错的。正确的做法是把“值变更”统一收敛到一个setFieldValue的入口规则求值挂在这个入口上不管值从哪来路径都一样。1.3 为什么不直接给业务一段 JS 表达式这个方案我认真评估过结论是作为兜底可以作为主方案不行。理由有三个。第一是配置态不可逆。业务配了一段form.a 1 form.b.length 2你想在界面上把它回显成一个可视化的条件树得写一个解析器业务想改其中一个值你得做 AST 变换再序列化回去。这个成本比一开始就结构化高得多。第二是安全与可控性。让配置人员写任意 JS等于把整个页面的执行环境交出去哪怕做了沙箱new Function这类东西在主流程里出现安全评审那一关就过不去。就算是内部系统我也倾向于把口子收窄只开放白名单函数。第三是排查成本。线上出问题的时候结构化规则我可以直接打日志规则 ID、条件求值结果、动作执行结果一眼看出是哪条规则没生效。表达式字符串只能打一个“结果 false”然后人肉去猜。我们后来做的规则追踪面板就是建立在这个结构化前提上的。所以我最终的选择是主链路用结构化 KOV配一个受限的表达式字段作为逃生舱表达式只允许引用当前表单的字段路径和一组白名单函数长度、包含、日期差之类不开放任意 JS。2. 数据结构与技术方案选型把规则设计成可演进的 DSL结构定义这一步如果偷懒后面每一次需求变更都会让你改核心代码。我在第二个项目里就吃过这个亏一开始规则是平铺的数组{field, op, value, action, target}跑得挺好直到业务要“满足 A 且B 或 C”平铺结构直接废掉只能推倒重来。所以这次我一开始就按树形结构设计。2.1 规则 DSL 的字段设计条件树用递归结构节点分两种逻辑组and/or/not和叶子KOV。动作列表挂在规则上一条规则可以带多个动作。下面是我实际用的类型定义简化了一部分业务字段。type FieldPath string; // 形如 base.amount 或 items[0].sku type OperatorId | eq | ne | in | notIn | gt | gte | lt | lte | between | contains | startsWith | regex | isEmpty | isNotEmpty | changed; interface KovLeaf { kind: leaf; key: FieldPath; operator: OperatorId; value: LiteralValue | ReferenceValue; // 常量或字段引用 } interface LogicGroup { kind: group; logic: and | or | not; children: ConditionNode[]; } type ConditionNode KovLeaf | LogicGroup; interface RuleAction { type: visible | hidden | disable | enable | required | optional | setValue | clearValue | setOptions | filterOptions; target: FieldPath; payload?: unknown; // setValue 的值、filterOptions 的过滤策略 } interface KovRule { id: string; name: string; // 给业务看的自然语言名必填 enabled: boolean; priority: number; // 数值越大越优先冲突时决定谁赢 when: ConditionNode; then: RuleAction[]; scope?: string; // 作用于哪个区块/子表单 remark?: string; }有几个字段是我特意加的值得单独说。name强制必填因为线上排查的时候你只会看到规则 ID没有可读名字根本不知道这条规则是干嘛的我们后来强制要求名字里带上业务语义比如“预付费单必填审批人”效果立竿见影。priority是为了解决动作冲突两条规则同时要求某个字段“必填”和“选填”没有优先级就只能靠数组顺序而数组顺序在可视化编辑器里是会被拖动的非常不可靠。scope是为了支持子表单同名字段在不同子表单实例里路径不同作用域能把规则限制在某个分支内。then设计成数组而不是单个动作也是为了减少规则数量。业务常见的一句话是“选了 A 就把 B 隐藏、把 B 的值清掉、把 C 设为必填”拆成三条规则会让配置界面上出现大量重复条件维护起来很痛苦。一条规则带多个动作既省配置又保证这几个动作是同一轮求值里执行的不会出现中间态。2.2 三条技术路线我为什么最后选了混合方案前端做联动常见三条路事件总线、依赖图、表达式求值。我在不同项目里都用过各自的脾气差别很大。方案实现方式优点致命问题适用阶段事件总线字段变更时 emit规则订阅上手快解耦好触发顺序不可控容易连锁触发循环规则少于 5 条的早期依赖图建字段依赖有向图拓扑序求值顺序确定可检测环需要维护图动态规则要重建规则 10 条以上表达式求值全量重算所有条件实现简单无状态性能差无法定位单条规则小表单、规则极少事件总线的问题我在第一个项目里体验得很彻底A 变触发 B 赋值B 赋值触发 C 显隐C 显隐又触发一条规则去改 A页面直接卡死控制台刷屏。你没法从代码上判断谁先谁后只能靠加setTimeout硬凑顺序这就是典型的用时间换正确性最后两边都没保住。纯表达式求值的思路是每次值变更就把所有规则的条件重算一遍逻辑上永远正确因为是无状态全量计算。小表单没问题字段上百、规则几十条的时候每次输入都跑一遍全量输入框会明显掉帧。我最终采用的是依赖图 增量求值的组合编译期规则保存时把规则解析成依赖图运行时按拓扑序分层求值值变更时只重算受影响的下游节点。这个方案的正确性来自拓扑序——同一层内的节点互不依赖可以并行算层与层之间严格顺序不会被赋值风暴打乱。性能来自增量——改一个叶子字段只波及它的下游子图跟规则总数无关。2.3 编译期与运行期分离一次编译多次执行这里有个设计决策值得展开。规则的解析不该放在每次渲染时做因为规则是配置态产物运行期基本不变。我把它拆成两个阶段编译期发生在规则集加载或保存时。做的事包括语法校验字段路径是否存在、操作符是否匹配字段类型、值类型是否合法、生成依赖图谁依赖谁、拓扑排序、环检测、把规则翻译成自然语言描述用于回显。编译结果是一份CompiledRuleSet包含图结构、拓扑层级、以及每条规则的执行函数闭包。运行期只做两件事接收值变更事件按拓扑层级调度执行把动作结果合并成一份渲染指令表RenderInstruction交给渲染层应用。这个拆法还有一个好处编译结果可以缓存。同一份规则在列表页和详情页都用只要规则 ID 和版本号没变直接用缓存省掉一次解析。我们线上规则集平均 30 条左右解析一次大概几毫秒缓存之后首屏基本感知不到。3. 核心实现拆解从字段寻址到渲染落地方案定了之后真正花时间的是细节。这一段我把几个关键环节的实现摊开讲包括路径寻址、依赖图构建、环检测、求值引擎和渲染应用中间会贴核心算法。3.1 字段路径寻址与 Schema 注册表单数据是嵌套的规则里的key必须是能唯一定位到某个字段的路径。我用的是点号加数组下标的形式base.amount、items[0].sku、approval.chain[2].approver。解析路径的代码不长但必须做得足够稳因为它是所有求值的基础。function resolvePath(data: any, path: string): unknown { const tokens path .replace(/\[(\d)\]/g, .$1) .split(.) .filter(Boolean); let cur data; for (const t of tokens) { if (cur null) return undefined; cur cur[t]; } return cur; }配套的是 Schema 注册表。每个字段在渲染时把自己注册进去登记路径、类型、当前值、可用的操作符、变更回调。规则求值时不直接读表单实例而是读注册表这样组件和表单库解耦换成任何表单方案都能接。这里有个坑要说清楚数组下标路径是不稳定的。子表单里删掉第一行原来items[1]的数据会变成items[0]规则如果绑死了下标就会串位。我的处理是子表单内部的规则使用相对路径作用域限定在实例内由实例自己去匹配跨实例的规则只允许引用实例的聚合属性比如items.length、items.sum(amount)。这个约定写进了配置规范禁止业务直接写下标。3.2 依赖图构建与拓扑排序依赖图的构建逻辑很直接遍历所有规则规则when里引用到的每个字段路径都指向then里每个动作的target。边方向是“被依赖字段 - 受影响字段”。同一条规则内部的多个 KOV边都指向所有动作目标。function buildGraph(rules: KovRule[]) { const nodes new Setstring(); const edges new Mapstring, Setstring(); // from - to const addEdge (from: string, to: string) { if (from to) return; // 自依赖规则内部问题单独告警 if (!edges.has(from)) edges.set(from, new Set()); edges.get(from)!.add(to); nodes.add(from); nodes.add(to); }; for (const rule of rules) { if (!rule.enabled) continue; const sources collectLeafKeys(rule.when); const targets rule.then.map(a a.target); for (const s of sources) for (const t of targets) addEdge(s, t); } return { nodes, edges }; }拓扑排序我用的是 Kahn 算法按入度分层出队。分层的好处是同一层的字段可以合并成一次渲染指令下发避免中间态闪烁跨层严格顺序保证求值结果的确定性。这里必须强调“确定性”——同样的输入必然得到同样的输出跟规则的存储顺序无关。之前用事件总线的时候改一下规则的数组顺序页面表现就变了这种不确定性在做配置化产品时是灾难。function topoLayers(nodes: Setstring, edges: Mapstring, Setstring) { const indeg new Mapstring, number(); nodes.forEach(n indeg.set(n, 0)); edges.forEach((tos) tos.forEach(t indeg.set(t, (indeg.get(t) ?? 0) 1))); const layers: string[][] []; let frontier [...nodes].filter(n (indeg.get(n) ?? 0) 0); const visited new Setstring(); while (frontier.length) { layers.push(frontier); const next: string[] []; for (const n of frontier) { visited.add(n); for (const t of edges.get(n) ?? []) { const d (indeg.get(t) ?? 0) - 1; indeg.set(t, d); if (d 0) next.push(t); } } frontier next; } return { layers, hasCycle: visited.size nodes.size }; }3.3 环检测与告警配置态就要拦住不能等到线上环是联动系统里最隐蔽的问题。A 的显隐依赖 BB 的赋值依赖 A这在单条规则看都没问题合起来就是死循环。Kahn 算法天然能检测环——如果最后访问过的节点数小于总节点数剩下的就是环上的节点。关键在于什么时候检测。我的做法是配置态实时检测用户在规则编辑器里每加一条规则就在本地重建一次图跑一遍检测发现环立刻在编辑器顶部弹提示指出哪几个字段构成了环并且禁止保存。上线前的规则集如果是从别处导入的加载时再跑一次历史上遗留下来的环也能兜住。光拦住还不够还得让业务看得懂。所以提示文案我做了本地化处理把字段路径翻译成字段标签输出成“审批状态 - 审批人 - 审批状态 之间存在循环依赖请调整规则顺序或拆分条件”。这句话比“检测到循环引用”有用得多业务能自己改。还有一种隐性环拓扑检测抓不到字段赋值触发了自身所在层的重算。比如 A 变触发 B 赋值B 又出现在 A 的条件里。这种情况在图上是有边的B - A拓扑排序会把它排到后面一层不会无限循环但会导致求值结果依赖执行轮次。我的处理是给赋值动作加“只在新值与原值不同时才真正写入”的判断值相同直接跳过绝大多数空转就此消失。3.4 求值引擎操作符体系与惰性求值求值引擎的核心是一个递归函数处理 LogicGroup 的短路求值和 KovLeaf 的操作符调用。短路这件事在小表单上感知不到规则一多就是实打实的性能差异——一个and组里第一个条件为假后面的引用和取值都不该发生。function evalNode(node: ConditionNode, ctx: EvalContext): boolean { if (node.kind group) { if (node.logic and) { for (const c of node.children) if (!evalNode(c, ctx)) return false; return true; } if (node.logic or) { for (const c of node.children) if (evalNode(c, ctx)) return true; return false; } return !evalNode(node.children[0], ctx); } const left ctx.getValue(node.key); const right isReference(node.value) ? ctx.getValue(node.value.ref) : node.value.literal; const op ctx.operatorRegistry.get(node.operator); if (!op) { ctx.warn(未注册的操作符: ${node.operator}); return false; } return op.test(left, right, ctx); }操作符注册表里每一项都是一个带元信息的对象实现上考虑空值语义。这块特别容易出 bug金额 gt 10000在金额为空的时候应该返回什么不同业务的预期不一样。我的约定是除了isEmpty/isNotEmpty/changed之外所有操作符遇到左侧为undefined/null/一律返回false并且不报错。这样“没填”天然不满足任何比较条件规则不生效符合直觉。如果业务需要“没填也算满足”就显式配一条isEmpty的规则别让操作符自己去猜。还有changed这个操作符需要特殊处理。它不比较值的大小而是判断“本轮是否发生过变更”需要引擎维护一个脏字段集合。这个操作符的用途是“用户主动改过这个字段才校验”避免初始化时一堆必填项全红。3.5 渲染层落地把规则结果转成指令表求值引擎输出的是动作列表渲染层不能直接在渲染过程中改状态那样会触发 React 的重复渲染警告也容易产生中间态。我的做法是让引擎先累积成一份指令表这一轮所有层的求值都跑完之后一次性下发。interface RenderInstruction { visible: MapFieldPath, boolean; disabled: MapFieldPath, boolean; required: MapFieldPath, boolean; values: MapFieldPath, unknown; // setValue / clearValue 的合并结果 options: MapFieldPath, OptionFilter; // 选项过滤策略 }合并规则要说清楚同一字段多条规则给冲突指令时按规则priority降序取第一个优先级相同则按规则 ID 字典序保证确定性。可见性和必填是布尔值直接覆盖赋值是后者覆盖前者但清空clearValue优先级高于赋值因为隐藏字段的残留值是最常见的脏数据来源。这里有一条我认为必须固化的原则字段被隐藏时它的值不参与提交但也不立刻清空。原因很简单用户切到 A 填了一堆切回 B 又切回来数据不该丢。真正的清空发生在提交前的裁剪阶段提交时按指令表把不可见字段剔除再送后端。但如果业务明确要求“切换就清空”就在规则里显式加clearValue语义由配置表达而不是组件偷偷决定。选项联动要单独处理异步。我的方案是给每次选项请求带一个自增序号回来的时候比对当前序号不匹配就丢弃。这个技巧简单但极其有效比 AbortController 兼容性好也不会因为有多个字段共用同一个数据源而互相干扰。3.6 性能增量重算与渲染合并规则少的时候性能不是问题规则多了之后真正的开销不在条件计算而在三处一是值变更引发的全量重算二是每个字段的订阅回调各自触发一次重渲染三是选项联动的重复请求。第一处的解法是增量。值变更时从依赖图里取出该字段的所有下游节点只重算这些节点涉及的规则而不是全量。实现上用edges做一次 BFS 拿到受影响集合再与规则索引求交。实测 40 条规则的表单单次输入的重算量从 40 条降到 3 到 5 条输入明显跟手了。第二处的解法是合并。同一轮里的所有指令合并成一次状态更新React 18 的自动批处理能帮一部分忙但跨await的更新不会自动合并所以我在引擎里显式做了批次管理一轮求值开始时收集结束时一次性提交。第三处的解法是缓存加去重。同一个数据源、同一组参数短时间内的请求直接走缓存参数变了但序号过期回包丢弃。我们还加了最小请求间隔防止用户拖动选择器时疯狂打接口。4. 配置态设计让业务自己配而不是每次都找开发组件做出来只是第一步更大的挑战是让业务能自己用。我们第一版把规则配成了 JSON 编辑器结果业务看一眼就跑了最后还是开发代劳。后来重做了配置界面规则配置量才真正转移到业务侧。4.1 规则编排器的交互结构现在的结构是“规则列表 规则详情”两栏。左边一列是规则的卡片列表每张卡片显示规则名、条件摘要自动翻译成中文、开关和优先级右边是详情编辑区条件部分用“条件组”的方式嵌套一组内可以选择“全部满足”或“任一满足”组可以继续嵌套。嵌套层级我限制在三层超过三层人的理解成本就超过收益了不如拆成多条规则。条件行的交互是三个下拉加一个输入选字段、选操作符、填值。操作符下拉按字段类型动态过滤值输入框按字段类型切换控件——日期字段出日期选择器枚举字段出下拉引用模式下切换成“选择字段”而不是“填值”。这个随类型切换的细节看着小实际体验差别很大业务不用去记“日期要写成什么格式”。动作部分做成勾选式勾了“隐藏”就自动禁用“必填”选项因为隐藏且必填是自相矛盾的配置。这类互斥校验前置到 UI 上比保存后再报错友好得多。我们统计过配置阶段的报错里有六成是这类逻辑矛盾拦在输入环节能省掉大量沟通。4.2 冲突检测与可读性回显冲突检测分三类。第一类是字段级冲突同一字段被两条优先级相同的规则要求“显示”和“隐藏”。第二类是可达性冲突某字段被规则永久隐藏但又被另一条规则设为必填这条规则永远不会生效。第三类是引用失效条件里引用的字段被删掉了。检测逻辑在保存时跑结果以警告形式列出不阻断保存但要求确认。为什么不一刀切禁止因为有些冲突是有意为之的比如节假日临时加一条规则覆盖默认逻辑这种靠优先级解决不算错误。但警告必须给让人知道自己做了什么。回显这块我做了一个“规则转自然语言”的函数把条件树翻译成中文句子显示在卡片上。比如“当 订单类型 等于 预付费 且 金额 大于 10000 时将 审批人 设为必填”。这个功能看起来是锦上添花实际使用中极大降低了维护成本业务扫一眼列表就知道自己配了什么不用点进去逐条看。function describe(node: ConditionNode): string { if (node.kind group) { const joiner node.logic and ? 且 : node.logic or ? 或 : 非 ; return node.children.map(describe).join(joiner); } const label getFieldLabel(node.key); const opText getOperatorLabel(node.operator); const valText isReference(node.value) ? getFieldLabel(node.value.ref) : formatValue(node.value.literal); return ${label} ${opText} ${valText}; }4.3 规则版本与灰度规则是配置配置就会改错。所以规则集我做了版本号每次保存生成一个快照线上运行时按版本号加载。出问题可以回滚到上一个版本这个能力在真实故障里救过我们一次——某次一条规则把必填项全关了导致一批单据带着空字段提交回滚之后五分钟恢复。灰度这块做得比较简单规则集带一个生效范围字段先在某些业务线上启用新版本观察一段时间没问题再全量。规则命中的日志会上报规则 ID、命中次数、动作类型跑一天就能看出哪些规则是死规则、哪些规则命中率高得异常。死规则定期清理异常规则重点看这套机制比人工 review 有效得多。5. 常见问题与排查实录下面这些问题都是我在实际项目里真遇到过的整理成速查表方便对照。表后面挑几条展开讲排查过程。现象可能原因排查手段处理方式字段该隐藏却一直显示规则未命中/优先级被覆盖开规则追踪看条件求值结果调优先级或修条件页面输入卡顿全量重算或渲染未合并打点统计单次求值耗时改增量合并指令选项错乱异步回包乱序打印请求序号与当前序号加序号比对丢弃过期回包初始化时联动不生效只在 onChange 触发规则检查赋值入口收敛到统一 setValue隐藏字段仍报错校验未读指令表看校验器是否过滤不可见提交前按指令裁剪页面偶发卡死规则成环拓扑排序检测配置态拦截禁止保存子表单串位用了绝对下标路径检查路径是否含[n]改相对路径 作用域5.1 赋值风暴一次输入触发几十次更新这个问题的表现是输入框打字明显卡顿Performance 面板里看到一秒内几十次 render。根因是赋值联动链路过长改 A 触发 BB 变化触发 CC 又触发 D每一跳都独立走一次状态更新。修复思路是把整条链压到一轮里跑完。具体做法是给引擎加一个“事务”概念进入求值时开启事务所有setValue不直接写状态而是写进事务内的待提交队列一轮拓扑求值全部结束后统一提交并只触发一次渲染。这个改动之后五跳的链条从五次 render 降到一次输入延迟肉眼可见地消失了。要注意的是事务内的取值必须读“待提交值”而不是“已提交值”否则后面的规则会读到旧值这是实现时最容易写错的地方。另外补一个经验赋值动作一定要做等值判断。setValue写入的值跟当前值相同就直接跳过不要触发下游。很多空转都是这么来的——规则本意是“跟随”但每次输入都重新赋一遍相同的值。5.2 隐藏字段的脏数据提交时才暴露这个坑很典型。字段被隐藏了界面上看不见用户以为不填也行结果提交的时候后端报“必填字段为空”或者更糟把一个之前填过的旧值悄悄提交上去了。根因是隐藏只改了渲染数据层没动。我的处理分两步。第一步隐藏时不清值但标记为“非活跃”规则引擎在后续求值中跳过非活跃字段的条件。第二步提交前执行裁剪按当前指令表把所有不可见字段从提交数据里剔除同时剔除它们的校验结果。这里要注意校验器必须读同一份指令表不能自己去判断可见性否则两边口径不一致又会出现“隐藏了但还在校验”的情况。还有一种边界情况字段被隐藏但它的值被另一条规则引用作为条件。这时候值不能剔除否则条件读不到。所以裁剪只发生在提交数据副本上不影响运行时状态。5.3 选项联动的竞态慢请求覆盖新结果用户先把一级分类从“电子”切到“服装”电子类的二级选项请求慢回来得晚把服装的选项覆盖了用户看到的是错的列表选了一个不存在的组合。这个 bug 在测试环境几乎复现不了因为网络快线上才出现。修法是请求序号。每次发起请求时seq并记录到局部变量回包时比对localSeq currentSeq不等就丢弃。代码就三行但能彻底解决。我还加了一个兜底选项回包后检查当前一级分类是否还是发起请求时的那个不等也丢弃。双保险因为有时候序号管理会因为组件重渲染而失效。顺带说一句缓存。同样的参数短时间内重复请求是浪费我按“字段路径 参数序列化”做 key 缓存有效期设得比较短30 秒左右既能挡住连续切换又不会让用户在后台改了配置之后长时间看到旧数据。5.4 规则越配越多治理比功能更重要做到后期真正的痛点不是技术是规则数量失控。一个表单配上四五十条规则没人敢动因为不知道删了会影响什么。我们做了两件事一是规则命中埋点跑一个月之后统计每条规则的命中次数零命中的直接归档二是依赖可视化选中某个字段能看到它被哪些规则引用、又被哪些动作影响删除前先看影响面。还有一条规范我觉得挺值规则必须写清楚名字和备注否则保存时提示。听起来像形式主义实际效果很好。半年后回来看一条叫“规则 23”的东西没人看得懂一条叫“预付费单金额超一万需二级审批”的一眼就明白。6. 这套方案上线之后我的几点实际体会整套东西从梳理场景到上线大概花了两个多月中间返工过一次数据结构。回头看最值的几个决策都不是技术上多精巧而是边界划得清。把 KOV 拆成结构化数据这件事短期看是给自己找麻烦要写编译器、要写回显、要写校验但长期看所有能力都建立在这上面包括规则追踪、自然语言回显、冲突检测、命中统计没有一个是靠表达式字符串能低成本做出来的。拓扑序求值这个决定当时还有同事建议用setTimeout分层来“模拟”顺序被我否了。用时间换顺序在本地跑得通一到线上机器负载高了就乱而且乱了之后没有任何手段能定位。确定性这件事在配置化系统里是不能妥协的。还有一个我开始没太在意、后来发现很重要的点规则执行的可观测性。我们后来加了一个调试面板开发环境默认打开能看到每条规则的命中情况、条件求值的中间结果、动作执行的顺序。这个面板在排查问题时省的时间远比开发它花的时间多。如果你的表单规则超过二十条我建议一开始就把这个口子留好哪怕先只打日志。最后提一句扩展方向。这套结构其实不只能用在表单上流程节点跳转条件、列表页的筛选联动、报表的参数联动本质都是 KOV 加动作差异只在动作的执行器上。我们后来把动作执行器做成可插拔的表单场景注册“显隐/赋值”执行器流程场景注册“跳转/驳回”执行器规则编辑器和求值引擎完全复用。这个复用带来的收益比我预想的要大得多。