简历回答逐字稿：低代码工作流引擎节点扩展系统

关联：简历追问：低代码工作流引擎节点扩展系统、15分钟：低代码平台。

30 秒开场

节点扩展系统我主要想解决的是：工作流能力一定会不断长新节点，如果每次新增节点都去改核心调度器，平台很快就不可维护。

所以我把节点能力拆成注册式插件。一个节点不只是前端组件，它要包含配置 Schema、配置面板、运行时 executor、输入输出定义、校验规则和错误标准化。核心引擎只负责调度生命周期，不关心 HTTP 节点、表单节点、条件节点内部怎么执行。

如果面试官问：一个节点插件具体包含什么？

我会说一个比较完整的 NodeDefinition 大概包括这些：

type NodeDefinition = {
  type: string
  version: string
  configSchema: ZodSchema
  outputSchema?: ZodSchema
  renderConfigPanel?: Component
  validate?: (config) => ValidationResult
  executor: NodeExecutor
}

configSchema 用来校验用户配置，outputSchema 用来告诉下游变量编辑器这个节点会产出什么，executor 是运行时真正执行逻辑。前端画布和后端运行时都围绕这个定义工作。

如果面试官追：注册模式和策略模式体现在哪里？

我会这样回答：

注册模式体现在核心引擎维护一个 registry，比如 registerNode('http', httpNodeDefinition)。调度器拿到节点 type 后，从 registry 取 executor，而不是写一堆 switch-case。

策略模式体现在不同节点有不同执行策略和校验策略。HTTP 节点要处理 URL、method、timeout、retry；Condition 节点要执行表达式并选择分支；Form 节点可能是等待用户提交。核心只约定输入、输出、状态和错误格式，具体策略由节点实现。

如果面试官追：新增 Webhook 节点要改哪些地方？

我会说理想情况下不改核心调度器。

新增 Webhook 节点需要做四件事：第一，定义配置 Schema，比如 URL、method、headers、鉴权、timeout、retry；第二，实现配置面板；第三，实现 executor，执行请求并把响应映射成标准输出；第四，定义 output schema，让下游可以引用响应字段。

核心调度器只看到它是一个会从 RUNNING 变成 SUCCESS 或 FAILED 的节点，不需要知道 Webhook 的业务细节。

如果面试官追：插件抛错怎么办？

我会说插件错误不能直接冒泡把流程引擎打崩。executor 外层会有统一包装，把异常转成标准 NodeExecutionError，比如：节点类型、节点 id、错误码、是否可重试、原始错误摘要。

对于可重试错误，比如 timeout，可以走 retry 策略；对于配置错误，比如 URL 非法，应该快速失败并提示配置修复；对于业务返回错误，比如 400，则作为节点失败输出，是否终止流程由流程策略决定。

如果面试官追：历史流程配置怎么兼容？

我会说节点版本一定要考虑。节点定义里带 version，配置里也记录 node type 和 version。插件升级时如果配置结构变了，需要提供 migration，比如从 v1 的 authToken 迁到 v2 的 auth: { type, token }。

发布时不能只测新配置，也要跑历史配置快照的兼容性测试。否则低代码平台很容易出现“核心升级以后老流程全坏”的问题。

收尾句

所以我理解的节点插件化，不是把 UI 组件动态加载一下，而是把配置、校验、执行、输出、错误和版本迁移都纳入同一个扩展协议里。这样平台才能长期加节点，而不是越加越乱。