Low-code / 低代码与流程

低代码平台为什么越用越重：表单、流程与扩展点的失控点

低代码的承诺是“业务人员拖拽就能上线”，现实往往是“配置越来越多、越来越难改、最后还是找开发”。平台不是不能用，而是要提前设计好边界和治理。

低代码平台通常从一个很具体的痛点出发：表单和审批变化频繁，写代码发版太慢。于是做表单设计器、流程设计器、规则配置，业务人员拖一拖就能上线。前期效果很好，但用上一两年，配置越来越多，平台越来越重，最后变成一套只有少数人敢改的“配置代码”。

一、低代码的承诺与代价

低代码降低的是“表达业务”的门槛，不是“理解业务”的门槛。它把一部分开发工作转移给了业务配置人员，同时把复杂度转移到了平台本身：模型、版本、权限、扩展、性能和治理。

• 配置是资产，也是债务。没有版本和治理的配置，比代码更难维护。
• 平台越灵活，越需要边界。否则每一个需求都会变成一个新的配置特例。
• 业务人员能配置，不等于能对结果负责。责任边界要提前定义。

二、模型先行：表单、流程、权限、数据

低代码平台的核心不是设计器，而是元数据模型。至少要把四类对象分开：

这四类对象必须解耦。表单升级不应该强制流程升级，权限变化也不应该改表单结构。解耦之后，平台才能独立演进。

三、扩展点：配置不够时怎么办

低代码最怕“配置到最后什么都能配”，因为那意味着平台在重新发明编程语言。更合理的做法是设计有限的扩展点：

• 事件钩子：在提交、审批、完成后触发受控脚本或服务调用。
• 自定义组件：允许接入经过审核的前端组件和后端服务。
• 规则表达式：沙箱执行，限制函数白名单、超时和外部 IO。
• 外部服务编排：通过接口描述调用外部系统，失败可重试、可补偿。

扩展点要有准入、审核和版本管理。否则平台会变成“什么都能塞”的容器，稳定性和安全性都无法保证。

四、版本与迁移

低代码平台的配置一旦上线，就会同时存在新实例和老实例。最稳妥的策略是：已发布的定义不可变，运行中的实例绑定启动时的版本。表单字段的变更要克制：

• 新增字段给默认值，保证老数据可渲染。
• 删除字段先隐藏、再停止写入、最后物理下线。
• 类型变更不要原地改，新增字段并做数据迁移。
• 关键表单保存提交时的快照，便于审计和追溯。

五、多租户与隔离

SaaS 场景下，租户之间要隔离数据、配置和权限。常见模式是共享表加租户 ID，配合强制过滤；对隔离要求高的客户，可以独立库或独立部署。无论哪种模式，租户 ID 都不能由业务代码自行决定，必须由网关统一注入。

配置也要按租户隔离。一个租户的流程和表单变更，不能影响其他租户。公共模板和租户定制要分层管理，避免复制粘贴造成配置漂移。

六、性能：配置解释器的成本

低代码平台在运行时解释配置，天然比硬编码多一层开销。表单渲染、规则执行、流程推进、数据查询都可能成为瓶颈。优化要从模型开始：

• 列表页只取必要字段，热字段单独建索引列。
• 规则表达式缓存编译结果，避免每次重新解析。
• 流程定义和表单 Schema 缓存，发布时失效。
• 大表单分片加载，避免一次渲染几百个字段。

七、治理：谁能为配置负责

低代码平台最容易失控的地方，是没有人对配置负责。业务人员改完就上线，出了问题找不到原因。平台需要提供：配置变更记录、发布审批、灰度发布、回滚、影响分析和监控告警。

配置也要有测试环境。至少能预览、能对比、能回滚，不能直接在生产的表单上改字段。把配置当成代码管理，平台才能长期可用。

八、什么时候不该用低代码

低代码适合规则相对稳定、变化频繁、以表单和流程为主的业务。以下场景不适合硬套：

• 强实时、强计算的高性能核心链路。
• 需要复杂算法、图形处理或深度定制的系统。
• 只有一次性需求、后续不再变化的项目。
• 团队没有配置治理能力，也没有测试和回滚机制。

小结

低代码平台的价值，不是让所有人都能拖拽，而是把高频变化收敛到可治理的配置层。模型先行、扩展点有限、版本不可变、配置可回滚、责任可追溯，这五件事做到，平台才会越用越轻，而不是越用越重。