结论先行：低代码（Low-Code）撑不撑得住，先分清是「业务真的变大了」还是「应用一开始就设计错了」。前者走扩容路线，后者要先重构。扩容有三条：纵向升级配置、横向拆分应用、迁出重建。多数中小企业的顺序是先用纵向争取 6~12 个月，再按业务边界横向拆，只有核心交易链路才值得迁出重建。

把「低代码上限低」当成结论，是把平台能力和应用设计混在一起谈。同一个平台，有人用它跑 20 人的审批，也有人用它跑 200 人的工单，差别通常不在平台，而在数据模型和流程设计。

五个容量预警信号

1. 列表加载变慢：单表数据超过 10 万行后，列表首屏加载超过 3 秒；
2. 并发报错：月底、季末集中提交时出现超时或重复提交；
3. 报表跑不动：跨表汇总需要等待数十秒，或直接超时；
4. 应用数量失控：同一业务域出现 5 个以上功能重叠的应用；
5. 变更互相影响：改一个表单，另一个应用的流程跟着出问题。

命中第 13 条，先查索引、分页与查询条件，很多「容量问题」其实是设计问题。命中第 45 条，说明该拆了。

路线一：纵向升级配置

触发条件：应用数量在 5 个以内，瓶颈集中在单应用的并发、存储或计算。

典型动作包括：提升数据库规格与连接数、给高频查询加索引、把报表改为定时预计算、把附件挪到独立对象存储、给接口加缓存。

• 代价：以资源费用为主，人力投入约 3~10 人天；
• 周期：1~2 周；
• 上限：能争取 6~12 个月的缓冲，但解决不了单应用职责过重的问题。

纵向升级是最先该做的一步，因为它便宜、可逆、不影响业务。缺点是它会把问题往后推，如果业务继续增长，迟早要面对拆分。

扩容所需的预算安排，见2026 年中小企业低代码预算怎么定。

路线二：横向拆分应用

触发条件：单应用承载了多个业务域，变更互相影响；或某张核心表被 5 个以上模块同时读写。

典型动作：按业务边界拆成 2~4 个应用，公共数据抽成独立的数据服务，应用之间通过接口或事件同步，而不是直接读对方的表。

• 代价：数据模型梳理 515 人天，接口开发 38 人天/个，历史数据拆分 3~10 人天；
• 周期：3~6 周；
• 风险：拆得太细会带来跨应用事务问题，拆分前要先定好「谁是数据的唯一写入方」。

横向拆分的关键不是技术，而是边界。按「谁产生数据、谁消费数据」划，比按部门划更稳定。

路线三：迁出重建

触发条件：核心交易链路（下单、收款、库存扣减）对一致性和性能有硬要求，或平台已明确不支持所需的并发量级。

典型动作：把核心链路迁到自有技术栈，低代码继续承担周边的管理类应用；迁移时保留原应用作为只读查询入口，跑一段时间再下线。

• 代价：按应用规模重估，通常 20~60 人天起，另加 3 个月的并行运行成本；
• 周期：2~4 个月；
• 前提：数据能全量导出、接口有文档、业务方接受一段时间的双系统运行。

迁出重建是三路线里代价最高的，所以只对「停摆一天就影响收入」的链路做。把所有应用都迁出去，等于放弃低代码带来的效率。

三条路线对照表

表中人天为通用场景区间，需按应用复杂度与团队熟练度调整。

决策顺序

1. 先做性能诊断，确认瓶颈在数据库、查询还是流程设计；
2. 能用纵向升级解决的，先升，观察 4 周是否复发；
3. 复发且原因是职责过重，进入横向拆分；
4. 拆分后仍不满足硬指标，再评估迁出重建。

跳过第 1 步直接迁出，是中小企业最常见的高成本错误：花两个月重建，结果发现原问题是列表没分页。

FAQs

Q1：低代码一般能撑住多少人同时使用？

A：没有统一数字，取决于部署方式与应用设计。自托管且数据库独立的情况下，百人级日常使用是常见区间；千人级以上要看并发峰值与核心链路复杂度，需要单独做容量评估，不能按平台宣传值直接套用。

Q2：拆分应用会不会让维护更麻烦？

A：短期会，长期不会。拆分后每个应用职责清晰，改一处不影响其他业务；代价是要维护接口契约和数据同步。建议拆分时同步建立接口文档与调用监控，否则问题会从「改不动」变成「找不到」。

Q3：什么时候该考虑迁出重建？

A：三个条件同时成立时：核心链路停摆一天就影响收入、平台已明确不支持所需并发量级、数据与接口都能完整导出。只满足一条就迁出，通常是过度反应。

延伸阅读

• 低代码平台并发容量规划：从 10 人到 1000 人
• 低代码平台技术架构怎么选？9大平台架构对比
• 老系统怎么用 AI 低代码翻新？遗留应用现代化的三步路线
• 中小企业最怕厂商倒闭：低代码选型的风险对冲