字段必填只是低代码表单校验的起点。本文说明如何分层设计格式、关联、状态与跨字段规则，并为例外处理保留可追踪入口。
低代码表单的字段校验，不应只判断“有没有填写”，还要验证数据格式、对象关系、业务状态和跨字段逻辑是否一致。合理的校验体系既能在录入时阻止明显错误，也会为确有依据的例外保留说明、审批和追踪路径。
表单是业务数据进入系统的主要入口。若只依赖必填设置，日期关系、停用档案、跨字段金额和审批后的关键数据仍可能出错。问题进入后续流程、统计或系统集成后，修正成本通常更高。
先把校验分成四个层次
第一层是完整性，判断当前动作所需字段是否存在；第二层是格式与范围，例如日期、编号、金额和附件类型；第三层是关系一致性，检查字段之间以及关联记录之间是否匹配；第四层是业务状态约束，决定在什么阶段、由什么角色可以填写或修改。
分层可以帮助团队识别规则应该放在哪里。简单格式适合在前端即时提示，涉及关联数据或权限的规则通常需要在保存或提交时由系统再次验证，关键业务结果还应在工作流节点执行前复核。
- 完整性：当前动作真正需要哪些输入；
- 格式范围：值的类型、长度、上下限和允许集合；
- 关系一致：多个字段或主表明细之间是否相互支持；
- 状态权限：当前记录状态和操作角色是否允许变更；
- 例外路径：不满足常规规则时由谁说明并确认。
错误提示要帮助使用者完成动作
“输入不合法”很难指导下一步。提示应说明哪个字段、违反什么规则以及怎样修正，例如“计划完成日期不能早于开始日期”或“当前供应商已停用，请重新选择”。提示应靠近问题字段，并在提交前汇总需要处理的项目。
即时提示适合不依赖服务器数据的规则，但不能成为唯一防线。多人协同或接口写入时，页面打开后的数据可能已经变化，因此保存、提交和工作流执行前仍需校验最新状态，避免仅靠浏览器端判断。
跨字段和关联数据规则要有明确来源
业务人员常说“这个组合不对”，系统建设需要把它转换成可执行条件。例如费用类型决定可选预算科目，项目状态决定是否允许新增任务，客户与合同必须属于同一主体。每条规则都应记录提出者、适用范围和变更依据。
使用明道云等低代码平台时，可以通过字段属性、筛选条件、计算、工作流和权限组合实现校验。若多个自动化同时判断同一规则，应明确主入口，避免一处允许保存、另一处又以不同口径退回。
例外不等于绕过规则
真实业务可能出现紧急采购、临时授信或资料后补。完全禁止会促使使用者转到线下处理，随意放开又会降低数据可信度。更合适的做法是提供例外申请，记录原因、附件、确认人、有效范围和到期时间。
例外通过后也不应删除原校验。系统可以保存“常规条件未满足但已获授权”的事实，并在报表或复核清单中单独展示。这样既支持业务连续，也保留责任和审计线索。
上线前怎样验收字段校验
测试样本应同时包含边界值、空值、重复值、停用关联对象、无权限角色、并发修改和接口写入。对每条规则至少验证正常通过、明确拒绝和授权例外三类结果，并检查提示内容是否准确。
规则维护也需要版本意识。当组织、制度或主数据发生变化，应知道哪些表单、工作流和接口依赖该规则。稳定的数据质量来自持续维护的业务定义，而不是不断增加无法解释的限制。
常见问题
低代码表单是否应该给所有字段设置必填？
不应该。必填项应与具体业务动作和阶段相关，只保留完成当前任务所需的最小输入。过多必填会导致使用者随意填值，也会让尚未产生的信息被迫提前录入。
字段校验应该放在表单还是工作流里？
简单格式和即时反馈可放在表单端，依赖最新数据、权限或业务状态的规则应在保存或工作流执行时再次校验。关键规则宜有唯一、可维护的主实现，避免多处口径不一致。
历史数据不符合新规则时怎么办？
先判断新规则是否需要追溯。可将历史记录标记为待治理，或仅在再次编辑、进入下一状态时要求补齐；不宜直接批量改写业务事实。迁移方案应保留原值和处理记录。
怎样判断校验规则是否过多？
如果大量记录通过随意填值、线下绕行或频繁申请例外才能继续，说明规则可能与实际业务不匹配。应结合错误频率、例外原因和后续使用价值，定期删除重复或缺少依据的限制。