当业务变复杂，低代码系统还能撑得住吗？

去年我们部门接了个内部系统升级任务，要把原来用某低代码平台搭建的供应链审批系统，改造成能支撑多事业部、跨境业务的新平台。这个旧系统已经跑了三年，初期确实帮我们快速上线，但后来问题越来越多。这次改造让我们彻底想清楚了一件事：低代码平台有它明确的能力边界，越界就是灾难的开始。

一、项目起点：低代码为什么被选中

五年前，公司只有一个事业部，采购流程简单：申请→部门经理批→采购执行。当时IT人力紧张，业务方急着要系统，就选了当时流行的低代码平台。

快速搭建是最大优点：拖拽表单、配置审批流，两周就上线了。初期效果很好：

➭ 流程变更时，业务管理员自己就能调整，不用找IT

➭ 基础的数据报表直接生成

➭ 移动端适配自动完成

二、问题开始浮现：复杂度增长超出预期

第二年公司开了新事业部，业务模式不同，审批流程开始分化：

1、流程分支爆炸：原来3个节点的流程，变成十几条分支规则

2、数据关联复杂：需要关联库存数据、供应商历史评价、合同条款

3、权限需求细化：不同事业部的人只能看到特定数据，同部门还有数据隔离

这时候我们发现，低代码平台的“可视化配置”开始变得笨重。要在界面上配置一个包含20个条件的审批分支，操作繁琐且容易出错。更麻烦的是，有些业务规则用平台提供的逻辑组件根本实现不了。

三、遭遇硬性技术限制

到了第三年，问题从“难用”变成了“无法实现”：

性能瓶颈明显：当单表数据超过50万条，平台生成的查询效率急剧下降。我们试图优化，但无法控制底层SQL生成逻辑。平台提供的“优化选项”很有限。

集成成本变高：需要和外部供应商系统对接，对方提供的是标准API接口，但低代码平台要求按特定格式封装。我们不得不在中间加了一层自研的适配服务，反而增加了系统复杂度。

定制化需求无处安放：业务需要复杂的成本分摊算法，涉及多个系统的数据实时计算。低代码平台的处理方式是定时任务跑批，但业务要求实时性。平台的计算引擎不支持我们写自定义算法。

四、我们尝试的补救措施

在决定重构前，我们尝试了几种方案：

1、混合开发模式：在低代码平台外部开发复杂功能，通过接口调用。结果是系统被拆得七零八落，维护更困难。

2、购买高级版：升级到平台的企业版，确实多了些功能，但核心限制还在。而且锁定效应越来越明显：代码完全依赖平台，想迁移都难。

3、二次开发绕路：用平台提供的“自定义代码”模块写复杂逻辑。但这带来新问题：调试困难、版本管理混乱、性能更差。

真正让我们下决心重构的，是下面这个具体场景：

财务部门需要动态计算采购预算占用，规则是：已审批未执行的订单占70%，已执行未入库的占100%，还要考虑汇率波动(跨境采购)。我们在低代码里用尽了各种办法，最终实现出来的方案：

➭ 计算一次需要15秒(业务要求3秒内)

➭ 规则稍有变动就需要重新配置整个流程

➭ 出错时没有任何有效的调试手段

五、重构方案：渐进式迁移

我们没有一夜之间替换整个系统，那样风险太大。而是制定了18个月的渐进迁移计划：

第一阶段：新功能用新架构

所有新增需求，只要涉及复杂逻辑，一律用自研系统实现。两个系统并行，通过单点登录和统一待办衔接。

第二阶段：核心流程逐个迁移

选择使用最频繁、问题最多的流程先迁移。我们选了采购申请流程，因为：

➭ 业务影响面大，能验证新架构的稳定性

➭ 逻辑复杂，能体现自研系统的优势

➭ 用户反馈直接，便于快速调整

第三阶段：数据迁移与旧系统下线

等所有核心流程都迁移完毕，用三个月时间并行运行，最后彻底关闭低代码系统。

六、技术选型的考量

新系统完全基于开源技术栈：

➭ 后端：Spring Boot + 自研工作流引擎

➭ 前端：Vue + 自研表单设计器(保留业务人员配置简单表单的能力)

➭ 数据库：按业务域分库，关键查询都经过人工优化

最重要决策：保留合适的配置化能力。我们没走回“一切硬编码”的老路，而是：

1、简单表单和基础流程仍支持可视化配置

2、复杂逻辑用代码实现，但提供清晰的接口

3、所有配置都有版本管理和回滚能力

七、遇到的挑战和解决方式

迁移过程并不顺利：

数据一致性难题：两个系统同时处理同一类业务时，状态同步很麻烦。我们最终引入了事件总线，任何状态变更都发事件，由专门的服务保证最终一致性。

用户习惯阻力：业务人员习惯了旧系统的操作方式。我们在新系统里尽量保持界面相似，同时针对痛点做改进，比如加载速度从平均8秒降到2秒内，用户才愿意接受改变。

团队技能转型：原来维护低代码的同事需要学习编程。我们安排结对编程，逐步过渡，现在他们既能写代码，也懂得在合适场景使用配置化方案。

八、现在的架构与反思

目前新系统已稳定运行一年多，支撑了五个事业部、每天上千条流程。总结下来，我们对低代码的定位更清晰了：

适合用低代码的场景：

➭ 生命周期短的工具型应用(6个月以内)

➭ 逻辑简单、变化频率低的内部工具

➭ 需要业务人员深度参与配置的标准流程

必须用传统开发的场景：

➭ 核心业务系统，预期使用3年以上

➭ 需要高性能、复杂计算的场景

➭ 需要深度定制和集成的场景

➭ 有长期技术演进规划的系统

九、给团队的具体建议

如果你也在评估或正在使用低代码：

1、一开始就要划定边界：明确哪些需求可以放在低代码里，哪些不行。最好有技术评审机制。

2、关注逃离成本：定期评估迁移到自研系统需要多少工作量，避免被平台锁定得太死。

3、保留数据控制权：确保核心业务数据存储在你能直接访问的数据库里，不要依赖平台私有存储。

4、性能测试要尽早：用接近真实的数据量测试，很多低代码平台在小数据量下表现尚可，数据一多就暴露问题。

5、建立过渡预案：设计架构时就要考虑未来如何迁移，比如接口要标准化，业务逻辑要模块化。

最后一点思考

低代码不是洪水猛兽，它确实解决了“快速交付简单应用”的需求。问题往往出在期望错配上：期待它能做超出设计范围的事情。

我们现在的策略是“混合架构”：标准、简单的流程用配置化平台(自研的轻量级平台)，核心复杂系统用传统开发。关键是保持技术选择的主动权，不被任何平台绑架。

做技术选型时，少看宣传文案，多分析自己的业务在复杂性、性能、集成、演进方向上的真实需求。系统撑不撑得住，不完全取决于技术本身，而更多取决于你的使用方式是否在它的能力边界之内。超出边界时，及时调整架构，比勉强修补更划算。