简历追问：低代码工作流引擎节点扩展系统

关联：全栈工程师简历 > 低代码工作流引擎、15分钟：低代码平台。

对应简历描述

设计了基于注册模式和策略模式的节点/组件扩展系统，实现了 Start、Form、HTTP、Condition 等核心节点的执行器，遵循开闭原则，方便后续业务组件库的低成本扩充。

面试官真正想确认

你说的“插件化”是不是有清晰接口、配置 Schema、运行时隔离和版本治理，而不是在核心里不断加 switch-case。

连续追问链

1. 扩展点定义

• 一个节点插件至少包含哪些东西：配置面板、配置 Schema、运行时 executor、输入输出类型、校验规则？
• Start、Form、HTTP、Condition 的 executor interface 是否相同？哪些能力由核心调度器提供？
• 节点输出如何声明，供下游变量编辑器引用？

2. 注册与策略

• registerNode() 或 registry 的 key 是什么？如何处理重名和版本？
• 策略模式体现在哪里？执行策略、校验策略、渲染策略是否拆开？
• 新增一个 LLM 节点是否需要改核心调度器？如果需要，说明边界没抽好在哪里？

3. 运行隔离

• HTTP 节点的超时、重试、鉴权、错误输出在哪里配置？
• Condition 节点执行表达式时是否能访问全局对象？如何防止不受控代码？
• 插件抛错会不会拖垮整个流程？核心如何把错误标准化？

4. 兼容与测试

• 插件配置 Schema 升级后，历史流程怎么迁移？
• 业务组件库如何做兼容性测试？核心升级会不会让老插件挂掉？
• 插件是否允许灰度发布和回滚？

场景推演题

现在要新增一个“Webhook 节点”：支持鉴权、超时、重试、把响应 JSON 暴露给下游。你要改哪些模块？哪些地方不能改？

继续追：如果 Webhook 节点返回字段结构变化，下游变量引用如何发现并提示？

准备证据

• 节点插件接口或伪代码。
• Form / HTTP / Condition 三个节点的配置 Schema 对比。
• 插件版本迁移策略。
• 插件异常标准化示例。

容易露馅的回答

• “新增节点就在 switch 里加一个 case。”
• “插件就是前端组件。”
• “节点输出靠文档约定。”
• “老流程不兼容就让用户重新配置。”