背景与目标
在整合 React / Vue / JSP 等遗留系统的过程中，遇到了一个普遍难题：
样式/行为需统一、技术栈混杂、开发成本高，而团队对重复性样式改造缺乏意愿。
为此，搭建了一个低代码平台，用于快速产出 B 端页面（如列表页、表单页、详情页），并计划逐步替换掉过时的遗留系统。
这些低代码页面最终需要接入一个由代码维护的中心系统，并支持页面间的跳转（如从列表页跳转至表单页、从详情页返回列表页等），因此系统集成方案成为关键课题。
本文将回顾我们从 Schema 渲染到微前端接入的技术演进路径，并结合实际落地经验，分析不同方案的利与弊。
系统约束
为了保证系统的一致性和可维护性，中心系统对接入页面提出了以下约束：
- 页面之间需共享统一的权限体系；
- 页面需接入中心系统的动态路由体系；
- 需支持页面独立演进，同时不破坏中心系统的稳定性。
技术方案演进路径
我们采用了“低代码生成页面 + 中心系统集成”的组合开发模式，演进过程大致如下：
Schema → 渲染引擎动态加载 → Schema 存储演进（DB → GitLab → OSS） → 代码生成 → 微前端子应用
下面是我们分阶段采用的两个核心方案：
方案一：Schema + 渲染引擎
初期，我们以 Schema（JSON 配置）形式产出页面描述，中心系统中持有通用渲染引擎。用户访问路由时，系统动态加载对应的 Schema 并实时渲染页面内容。
实施关键点：
-
路由映射机制：
页面保存后生成唯一 ID，由中心系统通过
/page/:id动态路由加载对应页面； -
页面跳转能力：
页面间跳转通过 URL 中的 ID 切换 Schema 实现，避免全量刷新；
-
Schema 存储与访问演进：
- 初期： Schema 存于数据库，便于增删改查；
- 中期： 迁移至 GitLab，实现版本控制；
- 最终： 上传至 OSS，通过 CDN 进行缓存与加速，提高访问性能并降低主系统压力。
这套方案帮助我们实现了低成本的页面搭建与业务快速试错，是低代码平台“跑起来”的关键起点。
方案二：微前端子应用
随着项目复杂度的提升，我们逐渐意识到：
Schema 驱动虽快，但表达能力有限，难以支持复杂交互逻辑和业务流程。
于是我们探索第二阶段：
将 Schema 编译为 React 代码，构建为微前端子应用，支持独立部署与开发者深度定制。
实施细节：
- 每个页面作为独立 Git 仓库，遵循阿里飞冰（ICE）的项目结构；
- 页面构建为微前端子应用，通过微前端的方式接入中心系统；
- 中心系统通过动态路由
/page/:pageID加载远程模块，实现页面的独立加载与更新。
这意味着：
- 页面可以独立开发、独立部署；
- 页面逻辑不再受限于 Schema 规范；
- 更符合中大型系统对“灵活性 +可维护性”的双重需求。
两种方案对比分析
| 对比维度 | Schema + 渲染引擎 | 微前端子应用 |
|---|---|---|
| 页面灵活性 | 配置驱动，能力有限 | 完全代码控制，支持任意扩展 |
| 页面性能 | 高（本地运行时渲染） | 高（预构建 + CDN 加速） |
| 系统耦合度 | Schema 与中心系统强耦合 | 子应用完全独立，解耦清晰 |
| 二次开发能力 | 限制多，维护成本较高 | 支持深度定制，程序员参与度高 |
| 上手门槛 | 较低，配置即生效 | 较高，需掌握工程化工具链 |
实践建议：场景选型参考
不同方案适用于不同业务阶段和复杂度，以下是我们的推荐参考：
| 场景 | 推荐方案 |
|---|---|
| 快速搭建低复杂度页面 | Schema + 渲染引擎 |
| 页面逻辑复杂、需定制化开发 | 微前端子应用 |
| 团队成员以产品/运营为主 | Schema 配置上手更快 |
实践总结
从 Schema 到微前端，是我们低代码平台自然演进的路径：
- 前期，Schema 驱动帮助我们快速搭建页面、验证业务思路；
- 后期，Schema 编译为代码，通过微前端方式解耦部署、增强灵活性，实现了高可维护、高扩展的工程化能力。
这是一条“从配置走向代码”的渐进式演化路径：
既服务了业务的快速落地，也兼顾了系统的长期演进和工程治理。
在企业里落地后，作者将自己的经验和思考总结后，出版为一本图书。更多内容可查看《低代码平台开发实践： 基于React》，书中覆盖完整开发流程，涉及业务需求分析→系统需求分析→架构设计→组件设计→引擎设计→渲染→代码生产→得到你的低代码平台。
因由于开发低代码平台具有较高的门槛，为了帮助读者轻松开发出属于自己的低代码平台，书中对协议、组件、设计器和代码生成器等低代码核心内容进行了详细解读，还配有可直接使用的源码和一个包含前端与后端代码的开源项目。
关于低代码的其他文章：
