背景与目标

在整合 React / Vue / JSP 等遗留系统的过程中，遇到了一个普遍难题：

样式/行为需统一、技术栈混杂、开发成本高，而团队对重复性样式改造缺乏意愿。

为此，搭建了一个低代码平台，用于快速产出 B 端页面（如列表页、表单页、详情页），并计划逐步替换掉过时的遗留系统。

这些低代码页面最终需要接入一个由代码维护的中心系统，并支持页面间的跳转（如从列表页跳转至表单页、从详情页返回列表页等），因此系统集成方案成为关键课题。

本文将回顾我们从 Schema 渲染到微前端接入的技术演进路径，并结合实际落地经验，分析不同方案的利与弊。

系统约束

为了保证系统的一致性和可维护性，中心系统对接入页面提出了以下约束：

• 页面之间需共享统一的权限体系；
• 页面需接入中心系统的动态路由体系；
• 需支持页面独立演进，同时不破坏中心系统的稳定性。

技术方案演进路径

我们采用了“低代码生成页面 + 中心系统集成”的组合开发模式，演进过程大致如下：

 代码解读
复制代码
Schema → 渲染引擎动态加载 → Schema 存储演进（DB → GitLab → OSS） → 代码生成 → 微前端子应用

下面是我们分阶段采用的两个核心方案：

方案一：Schema + 渲染引擎

初期，我们以 Schema（JSON 配置）形式产出页面描述，中心系统中持有通用渲染引擎。用户访问路由时，系统动态加载对应的 Schema 并实时渲染页面内容。

实施关键点：

1. 路由映射机制：

   页面保存后生成唯一 ID，由中心系统通过 /page/:id 动态路由加载对应页面；

2. 页面跳转能力：

   页面间跳转通过 URL 中的 ID 切换 Schema 实现，避免全量刷新；

3. Schema 存储与访问演进：

   • 初期： Schema 存于数据库，便于增删改查；
   • 中期： 迁移至 GitLab，实现版本控制；
   • 最终： 上传至 OSS，通过 CDN 进行缓存与加速，提高访问性能并降低主系统压力。

这套方案帮助我们实现了低成本的页面搭建与业务快速试错，是低代码平台“跑起来”的关键起点。

方案二：微前端子应用

随着项目复杂度的提升，我们逐渐意识到：

Schema 驱动虽快，但表达能力有限，难以支持复杂交互逻辑和业务流程。

于是我们探索第二阶段：

将 Schema 编译为 React 代码，构建为微前端子应用，支持独立部署与开发者深度定制。

实施细节：

• 每个页面作为独立 Git 仓库，遵循阿里飞冰（ICE）的项目结构；
• 页面构建为微前端子应用，通过微前端的方式接入中心系统；
• 中心系统通过动态路由 /page/:pageID 加载远程模块，实现页面的独立加载与更新。

这意味着：

• 页面可以独立开发、独立部署；
• 页面逻辑不再受限于 Schema 规范；
• 更符合中大型系统对“灵活性 +可维护性”的双重需求。

两种方案对比分析

实践建议：场景选型参考

不同方案适用于不同业务阶段和复杂度，以下是我们的推荐参考：

实践总结

从 Schema 到微前端，是我们低代码平台自然演进的路径：

• 前期，Schema 驱动帮助我们快速搭建页面、验证业务思路；
• 后期，Schema 编译为代码，通过微前端方式解耦部署、增强灵活性，实现了高可维护、高扩展的工程化能力。

这是一条“从配置走向代码”的渐进式演化路径：

既服务了业务的快速落地，也兼顾了系统的长期演进和工程治理。

在企业里落地后，作者将自己的经验和思考总结后，出版为一本图书。更多内容可查看《低代码平台开发实践： 基于React》，书中覆盖完整开发流程，涉及业务需求分析→系统需求分析→架构设计→组件设计→引擎设计→渲染→代码生产→得到你的低代码平台。

因由于开发低代码平台具有较高的门槛，为了帮助读者轻松开发出属于自己的低代码平台，书中对协议、组件、设计器和代码生成器等低代码核心内容进行了详细解读，还配有可直接使用的源码和一个包含前端与后端代码的开源项目。

关于低代码的其他文章：

1. 一句 Prompt 自动生成表单：我在低代码平台里是怎么接入生成式 AI 的
2. 在 AI 编程的热潮下对低代码的思考