低代码表单和在线问卷都能拖拽输入框、单选框、日期和附件，但它们解决的不是同一个问题。在线问卷面向一次调查活动，核心是把问题发给一群受访者，控制样本、回收答卷并生成统计；低代码表单面向持续运行的业务对象，核心是把结构化数据嵌入业务系统，与用户、组织、权限、流程、主数据和版本长期协同。
二者可以共享设计器、组件和条件表达式，却不能共用一套产品假设。问卷把"问题---答案---受访者---调查批次"作为中心；低代码表单把"字段---业务记录---操作人---业务状态"作为中心。把问卷工具当成企业表单引擎，通常会卡在数据更新、字段权限、复杂明细和流程协同；把低代码表单直接当问卷平台，则往往缺少匿名收集、邀请提醒、样本配额、随机化和统计分析。
本文从产品定位、数据模型、生命周期和技术架构四个层面说明边界，并以 FormCreate、JSON Forms、SurveyJS 和 LimeSurvey 的官方能力作为参照。
一、核心结论与问题边界
为什么两个产品看上去几乎一样
它们的设计态界面高度相似：左侧是组件或题型，中间是画布，右侧是属性面板，顶部有预览、保存和发布。单行文本、单选、多选、评分、矩阵、日期和文件上传也大量重合。因此，很多采购方会把"能不能拖拽出页面"当成唯一判断标准。
真正差异发生在提交之后。问卷提交后形成一份答卷，系统关心是否完成、来自哪个渠道、属于哪个样本、是否达到配额以及统计分布；业务表单提交后形成一条单据或主数据记录，系统关心谁能查看和修改、当前处于什么状态、能否退回重办、与客户或合同有什么关系以及历史版本如何回放。
设计器只是表层。产品定位由数据进入系统之后的生命周期决定。
一张表看懂核心差异
| 维度 | 低代码表单 | 在线问卷 |
|---|---|---|
| 核心目标 | 建模并运行持续变化的业务数据 | 发起调查并回收、分析一批答卷 |
| 中心对象 | 业务记录、字段、操作人、状态 | 问卷、题目、受访者、答卷 |
| 生命周期 | 创建、暂存、提交、审批、退回、修改、归档 | 设计、发布、邀请、填写、提交、统计、关闭 |
| 身份模式 | 登录用户、组织、角色、岗位与数据权限 | 匿名访问、公开链接、邀请码、样本名单 |
| 数据关系 | 主表、子表、关联对象、主数据、事务 | 问题答案、矩阵、答卷、参与者与调查批次 |
| 规则重点 | 字段权限、业务校验、联动、流程状态 | 跳题、随机化、配额、计分、完成条件 |
| 输出重点 | 单据详情、业务台账、流程、接口、打印 | 回收率、频数、比例、交叉分析与统计导出 |
| 典型场景 | OA、采购、合同、项目、巡检、主数据 | 满意度、市场调研、报名、测评、学术调查 |
这张表不是说二者互不相容。满意度调查可能需要工作流审核题目，业务申请也可能需要评分和匿名反馈。边界的意义是确定谁是主系统、谁提供专项能力。
产品定位不同：一个管理业务，一个完成调查
低代码表单的产品目标是降低业务应用的建模和变更成本。表单通常只是业务系统的一部分：员工填写采购申请，随后触发预算校验和审批；销售录入客户信息，数据进入客户主档；巡检人员提交隐患，后续形成整改任务。这些记录需要长期查询、修改、授权和关联。
在线问卷的产品目标是高效完成一次数据采集活动。运营人员发布客户满意度调查，通过公开链接、二维码、邮件或邀请码触达受访者，控制每人填写次数与样本配额，最后查看回收率、评分分布和统计结果。调查关闭后，核心成果是一批可分析的答卷。
因此，同样是"员工培训反馈"，若只做匿名评价和统计，问卷更合适；若反馈要自动生成整改事项、分派责任人并跟踪关闭，它已经进入业务应用范畴，需要低代码表单和流程能力承接。
二、关键概念与能力差异
界面相似，背后的设计模型不同
FormCreate 官方把自身定义为通过 JSON 生成动态表单的低代码组件，强调数据收集、校验、提交、自定义 Vue 组件、组件联动、子表和多 UI 框架。JSON Forms 则把数据 JSON Schema 与 UI Schema 分开：前者描述对象、属性和类型，后者描述控件、布局和可见性，并在运行时选择合适的渲染器。
SurveyJS 的设计器同样输出 JSON，但其结构围绕页面、问题、选项、题组和调查逻辑。官方文档中的 Logic 页签可配置显示、隐藏、跳转和计算；SurveyJS Form Library 根据调查配置呈现问卷。LimeSurvey 进一步提供参与者、邀请码、邀请和提醒、配额、响应统计与多种分析格式导出。
这说明"都输出 JSON"并不代表模型兼容。低代码表单的 JSON 往往要绑定业务字段、服务端类型和自定义组件；问卷 JSON 要表达题目顺序、选项、跳题、随机化、计分与答卷语义。转换可以做，但必须明确丢失或补充哪些语义。
低代码表单的数据模型为何更像业务数据库
业务表单中的字段通常有稳定编码和长期含义，例如合同编号、供应商、币种、含税金额、项目和成本中心。多个表单可能引用同一主数据；一张申请单可能包含多行采购明细；字段还要对应数据库类型、索引、查询条件、接口字段和打印模板。
因此，低代码表单需要处理对象关系：一对一、一对多、主表与子表、外键引用、字典、树形组织、附件和聚合金额。保存行为也不只产生新记录，还可能是暂存、更新、版本修订、批量导入、作废和恢复。
问卷更关注答卷的完整性。每次填写产生一组问题答案，问题可以包含矩阵、排序、动态面板和多选结果。即使允许"继续填写"或修改答卷，产品语义仍是维护一次响应，而不是长期编辑一张业务单据及其关联对象。
三、模型架构与运行机制
在线问卷为什么需要受访者与样本管理
业务系统通常先有用户账号，再根据组织、角色和数据范围决定能做什么。问卷却经常面对没有系统账号的人，因此需要公开链接、匿名模式、一次性邀请码、有效期、邀请邮件和重复提交控制。
LimeSurvey 官方的参与者功能可以导入名单、生成唯一邀请码、发送邀请和提醒、跟踪完成状态，并限制未收到邀请码或已完成者再次填写。配额功能可限制特定性别、年龄或地区样本数量。这样的能力不是普通字段权限可以替代的，因为它服务的是抽样和调查执行。
反过来，问卷的邀请码也不能替代企业身份。它通常只证明"某个受邀者可以完成这份调查"，无法自然表达该用户属于哪个部门、是否是合同负责人、能否查看下属数据以及在审批节点上拥有什么操作权。
生命周期不同决定了状态机不同
在线问卷的主状态通常是草稿、已发布、收集中、暂停或关闭；单份答卷则是未开始、填写中、已完成、被筛除或无效。发布后修改题目需要考虑统计口径，但大多数处理围绕一次调查活动展开。
低代码表单的状态通常由业务过程决定。一张合同申请可能经历拟稿、部门审批、法务审查、盖章、履约和归档；退回后重新编辑，审批通过后部分字段冻结；发生补充协议时又产生新版本。状态不仅影响按钮，也影响字段读写、数据关联、消息和外部接口。
如果用问卷的"提交完成"承接业务表单，提交后的修改、撤回、退回和归档会变得别扭；如果用业务单据状态承接问卷，又要额外开发样本筛选、未完成答卷和回收率计算。
四、核心场景与处理策略
跳题逻辑与业务流程不是一回事
问卷跳题决定受访者接下来看到哪个问题或页面。例如回答"没有购买过"时跳过使用体验题；分数低于 6 时显示原因追问。SurveyJS 的表达式和 Logic 页签支持条件显示、只读、计算与页面跳转，这些规则在一次填写会话中即时执行。
业务流程管理的是跨人员、跨时间的任务流转。提交采购申请后，部门负责人审批，金额超限再到财务和总经理，会签完成后回到申请人确认。流程需要任务、候选人、待办、历史轨迹、超时、驳回、撤回、加签和审计。
前端条件逻辑可以决定字段显示，却不能替代服务端流程状态；问卷页面跳转可以改变题目路径，却不能天然形成可追踪的多人任务。两者可以组合：表单内部用联动规则控制填写体验，外部由工作流引擎控制业务办理。
字段权限和匿名调查存在天然张力
低代码表单常见申请人可写、主管只读、财务可修改金额、人事可查看敏感字段等要求。权限计算依赖用户、部门、角色、岗位、流程节点和业务关系，而且必须在服务端再次执行，不能只在浏览器里隐藏控件。
问卷可能故意不保存受访者身份，目的是减少顾虑并满足匿名研究要求。即使使用邀请码，也可能采用答案与身份分离的设计，只记录谁完成了，不把身份直接附在答卷上。
因此，在需求评审时要先问清"匿名"到底意味着什么：不向分析人员展示姓名、数据库中不关联身份、还是系统完全不能恢复身份。若同时要求匿名和按部门追责整改，就存在业务冲突，不能靠勾选一个"匿名填写"选项解决。
五、数据、规则与状态设计
统计分析是问卷的主流程，不是附属报表
问卷平台在收集阶段就要考虑统计口径：单选与多选的频数和比例、评分均值、矩阵分布、完成率、渠道效果、受访者属性和配额。LimeSurvey 的结果区域区分完整与未完成答卷，提供快速图表和完整统计，并支持导出 Excel、CSV、SPSS、R、STATA 等格式继续分析。
低代码表单当然也需要报表，但通常围绕业务台账、金额汇总、处理时长、状态分布和权限范围。报表字段可能来自多个业务对象，并受到组织和数据权限控制。它更接近业务分析或数据仓库，而不是对一份调查问卷做题目级统计。
若项目的成功指标是"回收 1000 份样本并分析 NPS"，优先选择问卷平台；若指标是"让 1000 张申请单在多部门协同中按规则办结"，应以表单与流程平台为主。
发布与版本控制为什么不能照搬
问卷发布后修改选项，会影响前后答卷的统计可比性。因此平台通常限制已发布问卷的结构变更，或者要求复制为新调查。版本边界以调查批次和统计口径为中心。
业务表单的版本边界以业务记录和流程实例为中心。新申请使用新模型，历史记录仍需按原版本查看；字段升级可能需要数据迁移，旧流程实例还要继续运行。组件升级也要兼容旧模型，不能因为 UI 库变化就让历史单据无法打开。
两者都需要版本，但版本对象和兼容目标不同。问卷重点保护样本可比性，业务表单重点保护历史业务事实和运行中的流程。
六、工程实现与系统集成
技术架构应该怎样划分
低代码表单平台通常包括设计器、Schema 仓库、统一渲染器、业务组件、服务端校验、实例数据、组织权限、工作流和开放 API。JSON Forms 的核心层独立于 UI 技术，并通过不同框架绑定和渲染器集合扩展；FormCreate 则强调 JSON 规则、动态渲染、双向绑定和 Vue 组件扩展。这些能力适合嵌入业务应用。
在线问卷平台通常包括问卷设计器、调查运行时、渠道与链接、参与者管理、邀请提醒、答卷存储、配额、反作弊、统计和导出。SurveyJS 允许把设计器和表单库嵌入不同前端框架，但官方明确说明 Survey Creator 的商业集成需要购买许可；LimeSurvey 则提供较完整的开源问卷平台能力。
共同层可以复用组件、主题、国际化、校验和表达式；专用层不要强行合并。企业若同时需要两类能力，最稳妥的方式是共享身份、消息、文件和数据交换基础设施，同时保留业务表单实例库与问卷答卷库两套领域模型。
哪些场景应该明确选择在线问卷
客户满意度、品牌调研、员工敬业度、课程评价、考试测评、活动报名和学术研究，通常更适合在线问卷。尤其当需求包含公开链接、匿名回答、邀请码、样本配额、随机题序、题库抽题、计分、回收率和统计导出时，问卷平台的领域能力更直接。
报名表是容易混淆的边界案例。若只是收集姓名、联系方式和场次并统计人数，它仍可视为问卷；若报名后要审核资格、缴费、开票、分配座位、变更和退款，就应进入业务系统，问卷只负责入口采集。
七、安全、性能与治理要求
哪些场景应该明确选择低代码表单
请假、采购、合同、费用、客户、项目、巡检、隐患整改、资产和主数据维护，更适合低代码表单。这些场景具有登录身份、长期记录、复杂字段权限、多表关系、流程状态、反复修改、打印和外部系统集成。
判断标准不是表单有多少字段，而是数据提交后是否继续参与业务。如果一条记录会被多人处理、反复更新、与其他对象关联并接受审计，它就是业务对象，不应只作为一份答卷保存。
混合场景如何设计才不混乱
企业可以让问卷负责外部或匿名采集，再将合格结果转换为业务记录。例如供应商准入先通过公开问卷收集基础资料，完成身份核验后再创建供应商申请单并进入审批。此时要记录来源问卷、答卷编号、转换时间和字段映射，而不是让审批直接修改原始答卷。
另一种方式是在业务应用中嵌入问卷组件。项目结项后，系统向参与者发送满意度问卷；答卷统计保留在问卷域，业务系统只保存调查批次、完成状态和关键指标。这样既保持问卷分析能力，也避免把匿名原始答案散落到业务表中。
关键原则是"领域分开、事件连接"：问卷完成可以发布事件，业务平台据此建单或更新状态；业务对象变化也可以触发调查邀请。不要让同一张数据表同时承担答卷、业务单据和流程变量三种职责。
八、平台落地、测试与选型
企业选型时应该问哪些问题
第一，数据提交后是结束，还是业务办理的开始？如果提交后还要审批、修改和归档，优先低代码表单。
第二，填写人是否一定拥有企业账号？如果大量外部和匿名受访者参与，需要问卷的渠道与参与者能力。
第三，主要规则是题目跳转、随机化和配额，还是组织权限、业务校验和流程状态？规则对象决定产品内核。
第四，结果主要进入统计分析，还是进入业务台账和其他系统？前者要求答卷与统计模型，后者要求业务对象和接口模型。
第五，已发布内容怎样变更？要分别验证调查口径保护和业务历史版本回放，不能只看"支持版本管理"四个字。
第六，商业授权是否允许嵌入产品。开源运行库、设计器和分析组件可能采用不同许可证，SurveyJS 的官方文档就明确区分在线生成配置与商业集成设计器的授权。
选型边界流程
若数据提交后只用于汇总、评价和研究，而且存在匿名、邀请、配额或随机化，选择在线问卷。若提交后进入多人办理、反复变更、权限控制和系统集成，选择低代码表单与流程平台。
若两类特征同时存在，不要用一个产品勉强覆盖全部。确定主领域后，通过接口和事件连接另一类工具：问卷负责采集与统计，业务平台负责建单与办理；或者业务平台负责身份和触发，问卷平台负责匿名反馈。
在云程低代码开发平台这类企业应用平台中，表单应与数据模型、组织权限、工作流、门户和移动端形成统一运行链路；若企业还需要大规模调查，可以接入专业问卷系统，而不是把业务表单设计器改造成一套不完整的问卷平台。
