先给结论：电子表单是用户最终填写和查看的数字化载体；动态表单是由元数据在运行时解释生成、可以随配置变化的表单；表单设计器是制作表单模型的可视化工具；表单引擎则是负责模型、渲染、规则、数据、权限、版本、发布和集成的一整套运行体系。
这四个词经常被放在同一张产品宣传页上，但它们并不处于同一个层次。一个网页表单可以是电子表单，却不一定是动态表单；一套系统可以通过 JSON 渲染动态表单，却没有拖拽设计器；一个界面很好看的设计器，也可能只会输出 JSON，远未达到企业级表单引擎的能力边界。
本文用 Formily、FormCreate、SurveyJS 和 JSON Forms 等开源项目说明四个概念的定位，并以请假申请为例，给出企业选型时真正应该检查的能力清单。
一、核心结论与问题边界
一句话回答：四个概念不是四种互斥产品
四者更像"使用结果---实现方式---生产工具---平台能力"的关系：
- 电子表单回答"用户在填什么"。它可以是网页、移动端页面、平板采集页，也可以是由 PDF 或传统纸表数字化而来的录入界面。
- 动态表单回答"表单怎样被生成和改变"。字段、布局、校验、显隐和联动通常不写死在页面代码中，而是在运行时读取 Schema 或元数据。
- 表单设计器回答"业务人员怎样制作这些元数据"。它把字段库、画布、属性面板和预览能力组合成可视化编辑环境。
- 表单引擎回答"表单从设计到生产运行怎样被统一管理"。它不仅生成页面，还承担版本、权限、数据、规则、发布、审计和系统集成。
所以，动态表单不是电子表单的反义词，设计器也不是引擎的同义词。设计器通常是表单引擎的一个组成部分，而动态渲染器是另一个组成部分。
先用一张表看懂四者区别
| 概念 | 核心对象 | 主要使用者 | 典型输入 | 典型输出 | 是否必须包含拖拽设计 |
|---|---|---|---|---|---|
| 电子表单 | 一张可填写、查看或提交的数字表单 | 最终用户 | 页面配置或固定页面 | 表单数据 | 否 |
| 动态表单 | 运行时可解释的表单模型 | 开发、配置人员 | JSON Schema、规则、元数据 | 随配置生成的 UI 与数据 | 否 |
| 表单设计器 | 表单模型的可视化生产工具 | 业务人员、实施人员 | 拖拽、属性配置、模板 | Schema、JSON、DSL 或代码 | 通常是 |
| 表单引擎 | 表单全生命周期运行平台 | 业务、开发、运维、审计 | 模型、规则、数据、权限 | 可发布、可治理的业务表单应用 | 可包含但非唯一能力 |
判断一个产品是什么，不要看它给自己起了什么名字，要看它管理的核心对象与运行责任。只提供十几个组件和一个拖拽画布的项目，更准确的称呼通常是"表单设计器"；能按照 JSON 生成 Vue 页面的是"动态表单框架"；只有当模型、运行时和企业治理形成闭环，才适合称为"表单引擎"。
二、关键概念与能力差异
什么是电子表单
电子表单是纸质表单的数字化表达，但它并不等于"把纸张做成网页"。它至少应支持字段录入、格式校验、数据提交、保存和查询，并根据设备提供合理的交互。
电子表单可以采用两种实现方式。第一种是开发人员用 Vue、React 或原生 HTML 固定编写，每次改变字段都重新开发和发布；第二种是运行时读取元数据生成页面。前者仍然是电子表单，只是它不是动态表单。
常见场景包括采购申请、客户登记、设备巡检、报销单、调查问卷、政务申报和移动端数据采集。对最终用户来说，他看到的是一张电子表单；至于页面背后由固定代码还是 Schema 生成，并不是电子表单这个概念要回答的问题。
什么是动态表单
动态表单的"动态"不是指页面上有动画，也不只是字段联动。它的本质是：表单结构和行为由可解释的模型驱动，运行时根据模型生成页面。
一个典型模型会描述字段标识、数据类型、组件类型、默认值、校验规则、布局、可见性、只读状态、选项来源和联动表达式。修改模型后，同一套渲染器即可生成另一张表单，通常不需要重新编译业务页面。
这里要特别区分数据 Schema 与界面 Schema。标准 JSON Schema 擅长说明数据类型、必填、枚举和约束，却不完整描述网格布局、标签位置、组件选择和交互行为。因此，主流项目通常采用两种办法：像 JSON Forms 那样把数据 Schema 与 UI Schema 分开；或者像 Formily 那样增加 x-component、x-reactions、x-visible 等扩展字段。把任意 JSON 都称作"标准 JSON Schema"并不严谨。
动态表单的优势是复用和快速变化，但它也带来新的工程问题：模型兼容、表达式安全、复杂联动性能、组件注册、服务端校验和历史版本回放。它把变化从代码迁移到了元数据，并没有让复杂性消失。
三、模型架构与运行机制
什么是表单设计器
表单设计器是一个创作环境，通常由组件工具箱、设计画布、层级结构、属性面板、数据源配置、预览和撤销重做组成。设计器最重要的产物不是截图，而是可被运行时解释的表单模型。
优秀的设计器要解决三类问题：一是让业务人员快速放置字段和布局；二是限制错误配置，例如字段编码冲突、循环联动和无效表达式；三是保证所见所得，即设计态、预览态和生产运行态使用一致的组件语义。
但是，能拖拽并不代表可以直接投入企业生产。设计器可能只负责生成一段 JSON，不负责数据保存、权限控制、发布审批、模型版本、租户隔离和审计。购买或采用开源设计器时，必须继续追问"这段配置由谁执行、数据存在哪里、旧版本怎样打开"。
什么是表单引擎
表单引擎是一套围绕表单模型和表单实例数据运行的基础设施。它至少包含设计态、运行态和治理态三部分。
设计态负责组件、布局、数据模型、校验和规则配置；运行态负责 Web 与移动端渲染、数据绑定、联动计算、提交和服务端校验；治理态负责模型版本、发布环境、权限、审计、数据迁移、监控和集成。企业级产品还要处理附件、打印、导入导出、国际化、无障碍和国产化环境。
表单引擎的真正难点不在"把 JSON 变成输入框"，而在长期兼容。例如某张报销单已经产生十万条数据，后来删除了字段、改变了金额精度并更换了组织权限，历史单据仍要按当时版本正确展示和审计。只有管理模型版本、数据版本和组件版本之间的关系，才能称为稳定的引擎。
四、核心场景与处理策略
四者如何组成一条完整链路
设计器产生表单 Schema；引擎保存、校验和发布 Schema；动态渲染器在运行时解释 Schema；最终用户看到并填写电子表单。提交的数据再经过服务端规则、权限和流程处理，形成表单实例。
这条链路中，每层都可以独立替换。企业可以使用自研设计器生成 Formily Schema，也可以没有设计器而由开发人员手写 JSON Forms 的 UI Schema；还可以把 SurveyJS Creator 作为设计端，把表单定义和结果保存到自己的后端。理解这种解耦关系，选型时就不会被"一个 Demo 同时出现拖拽和预览"误导。
Formily：更像高性能动态表单框架
Formily 由阿里巴巴开源，官方定位强调跨终端、高性能的表单解决方案，支持 React、React Native、Vue 2 和 Vue 3。它既能处理普通表单，也能以 JSON Schema 驱动动态表单，并把字段状态、联动副作用和 UI 组件做了较清晰的分层。
Formily 的代表性设计是字段级响应式状态管理。字段变化不必让整棵表单树重新渲染，适合字段多、联动复杂的业务表单。它的 Schema 通过 x-* 扩展描述组件、装饰器、显示状态和响应关系，说明"数据标准"与"界面协议"通常需要配合使用。
但 Formily 本身更接近前端表单框架和协议体系。企业仍需要补充可视化设计、模型仓库、服务端校验、数据权限、版本发布和流程集成。因此，把 Formily 直接等同于完整表单引擎，会高估它开箱即用的范围。
五、数据、规则与状态设计
FormCreate：动态渲染器与设计器可以分开
FormCreate 面向 Vue，通过 JSON 规则生成表单，支持 Element Plus、Ant Design Vue、Naive UI、Arco Design、TDesign、Vant 等多个 UI 体系。官方将运行库与 @form-create/designer 分开发布，这正好说明动态表单与表单设计器并不是同一个模块。
开发团队可以只采用渲染器，在业务代码中生成或维护规则；也可以引入设计器，让实施人员拖拽配置。它适合快速构建 Vue 动态表单和后台管理类项目，但权限、持久化、发布、审计、数据模型治理等能力仍需要上层平台提供。
SurveyJS：最直观展示设计器与运行库的分工
SurveyJS 的产品结构非常适合解释本题。Survey Creator 是可视化表单设计器，左侧是题型工具箱，中间是画布，右侧是属性配置；SurveyJS Form Library 则是在 React、Angular、Vue 3 或原生 JavaScript 应用中渲染表单的运行库。设计器生成 JSON 定义，运行库消费该定义，业务系统负责保存模型与答案。
需要注意其授权边界。官方说明 Form Library 采用 MIT 许可证，而 Survey Creator、Dashboard 和 PDF Generator 属于商业库并提供源代码访问。技术上"源码可见"不必然等于"可免费商用"，企业选型时必须分别核对每个组件的许可证和订阅条款。
SurveyJS 擅长调查问卷、测评和数据采集，也能承载一般表单。若要形成 OA 或低代码平台，还要增加组织权限、业务主键、单据状态、流程绑定、数据范围和多环境发布。
六、工程实现与系统集成
JSON Forms：为什么数据 Schema 和 UI Schema 要分开
JSON Forms 是一个很有代表性的 Schema 驱动表单框架。它以 JSON Schema 描述数据结构与校验，再以 UI Schema 描述控件、布局和规则。渲染器根据控件适用条件选择具体组件，从而允许不同 UI 组件库复用同一份数据定义。
这种分离有两个价值。第一，数据约束不被某个前端框架绑死，可以在服务端再次校验；第二，同一数据模型可以拥有桌面端、移动端或只读详情等不同 UI Schema。代价是模型数量增加，设计器必须同时理解数据路径和布局结构，版本管理也要保证两者兼容。
因此，动态表单协议没有唯一答案。单 Schema 更直观，双 Schema 更强调职责分离，带扩展字段的 Schema 更方便表达复杂交互。选型应看协议能否稳定演进、是否可迁移，而不是只比较字段数量。
用请假申请说明四者如何协作
以请假申请为例，实施人员先在设计器中放置请假类型、开始时间、结束时间、天数、原因和附件，并配置"年假显示剩余额度""结束时间不得早于开始时间"等规则。设计器输出版本化的表单 Schema。
发布后，表单引擎检查字段编码和规则，生成正式版本并绑定请假业务。员工打开应用时，动态渲染器读取对应版本，解析布局、组件、字典、权限和联动，最终呈现一张电子表单。
员工提交后，浏览器校验只能改善体验，服务端仍要重新校验日期、额度和字段权限。表单实例与流程实例建立关联，主管看到审批所需字段，人事能够查看合规信息，而无权限人员看不到敏感原因。以后表单增加"交接人"，新申请使用新版本，历史申请继续按旧版本回放。
在云程低代码开发平台这类面向业务审批的平台中，表单不能只和页面组件绑定，还要与流程节点、按钮权限、字段读写权限、业务单据状态和数据范围协同。这也是通用开源表单框架与企业低代码表单引擎之间的主要差距。 
七、安全、性能与治理要求
为什么"能拖拽"不等于拥有表单引擎
一个常见误区是用拖拽体验判断技术成熟度。拖动输入框、设置标题、导出 JSON，只验证了设计器最表层的能力。企业项目还应做以下测试：
- 修改已发布表单后，历史数据能否按原版本查看，旧 API 是否继续兼容。
- 隐藏字段、只读字段和无权字段是否在服务端同样受控，能否阻止伪造请求越权提交。
- 联动表达式是否有沙箱、超时和循环依赖检查，能否避免执行任意脚本。
- 字典和远程数据源不可用时如何降级，表单是否支持缓存、重试和监控。
- 大表单、子表、多级联动和批量明细在低端移动设备上是否仍能流畅使用。
- 模型、组件、数据和流程的版本如何关联，是否支持灰度、回滚和审计。
这些问题大多不体现在演示界面，却决定系统能否运行五年或十年。
企业级表单引擎还需要哪些能力
| 能力域 | 必要能力 | 常见风险 |
|---|---|---|
| 模型治理 | 唯一编码、版本、发布、回滚、差异比较、模板继承 | 修改模型导致历史单据无法打开 |
| 数据治理 | 主从表、附件、精度、查询索引、归档、数据迁移 | 只有 JSON 大字段，难查询和统计 |
| 规则校验 | 前后端一致校验、联动、计算、远程校验、循环检测 | 只做前端校验，可被绕过 |
| 权限安全 | 表单、按钮、字段、行级数据权限、脱敏、租户隔离 | 隐藏字段仍能被接口读取或篡改 |
| 多端体验 | PC、移动端、只读页、打印、无障碍、国际化 | 设计态好看，移动端不可用 |
| 流程集成 | 节点表单、字段读写、业务状态、意见、暂存和退回 | 表单状态与流程状态相互覆盖 |
| 运维集成 | 日志、审计、监控、告警、缓存、开放 API | 规则出错后无法定位具体模型版本 |
还有一个经常被忽视的原则：前端规则不应成为唯一事实来源。必填、金额范围、数据权限和业务约束必须能在可信服务端再次执行；客户端传回的计算值和隐藏字段都不能直接相信。
八、平台落地、测试与选型
开源项目应该怎样选
如果团队主要需要在 Vue 或 React 项目中构建复杂、联动较多的业务表单，并愿意自己建设后端治理，可以重点评估 Formily。它对字段状态和响应式联动的抽象较深入，但学习成本和协议扩展也需要纳入维护预算。
如果项目以 Vue 为主，希望快速获得 JSON 渲染和拖拽设计能力，可以评估 FormCreate。采用前要明确运行器、设计器、UI 组件库及自研业务组件的版本兼容策略。
如果场景偏调查、问卷、测评和数据采集，并希望获得成熟的可视化设计体验，可以评估 SurveyJS，同时逐项核对 Form Library 与 Creator 等组件的授权差异。
如果组织重视标准化的数据 Schema、UI 与数据分离、跨渲染器适配，可以评估 JSON Forms。它更像可组合的前端基础能力，平台级治理仍要自行建设。
如果需求是 OA 审批、政务申报或企业低代码平台，选型对象不应只是一款前端表单库。更稳妥的方案是先定义企业表单协议和治理边界，再把开源渲染器或设计器作为可替换组件接入。
一套实用的选型检查顺序
第一步，先分清目标。是做十张固定电子表单，还是做允许业务人员长期配置的动态表单平台？固定需求用普通前端开发可能更简单，不必为了"低代码"引入复杂引擎。
第二步，检查模型。Schema 能否表达数据、布局、校验、联动、数据源和权限？是否有明确版本号、稳定标识和迁移机制？能否从系统导出，避免被私有协议永久锁定？
第三步，检查运行时。关注大表单性能、移动端、组件扩展、错误隔离、服务端校验、离线或弱网，以及不可信表达式的安全边界。
第四步，检查治理。用真实的"发布后改字段、历史数据回放、跨版本统计、离职权限变更、流程退回重填"场景验证，而不是只看产品演示。
第五步，检查许可证和维护。分别核对核心库、设计器、报表、PDF、UI 组件和第三方依赖的授权；评估社区版本、商业版本和自研扩展的长期总成本。