跳到主要内容

前端融合开发方式

前端定制按五个承载层选择交付方式：

  • 页面级：业务页面、独立子应用、自定义登录页
  • 壳层级：顶栏、侧栏、导航和整体框架
  • 页面内复用级：低代码页面里的可复用控件
  • 跨应用分发级：把一批前端能力发给多个应用复用
  • 门户拼装级：工作台、看板、仪表板、首页入口组织

错误选择通常表现为：

  • 本来只要补一个控件，却直接起了一个整页微前端
  • 本来只是想改壳层，却把业务页面逻辑塞进布局组件
  • 本来只是一个应用内复用，却过早做成平台组件库
  • 本来只要做首页拼装，却误走成独立子系统开发

一张总判断表​

当前需求优先方式说明
做一整页复杂交互、独立子应用或特殊业务界面微前端页面页面级承载
替换默认登录体验和认证入口组织自定义登录页特殊页面级承载
替换顶栏、侧栏、导航和平台壳层布局组件壳层级承载
给低代码页面补一个可复用控件组件库页面内复用级承载
把一批前端能力分发给多个应用复用平台组件库跨应用分发级承载
做首页、工作台、门户、看板拼装工作台 / Widget门户拼装级承载

先理解五类方式分别解决什么问题​

微前端页面​

适合承接完整页面、复杂交互或一组独立路由页面。

如果你的需求本质上是“这是一块独立前端界面”，通常优先从微前端页面开始，而不是先改布局或组件库。

自定义登录页​

适合替换默认 /login 体验，统一品牌视觉，或重新组织本地登录、LDAP、CAS、OAuth2/OIDC 等认证入口。

它本质上也是微前端的一种特殊落点，但它解决的是登录体验和认证入口问题，而不是普通业务页面问题。

布局组件​

适合替换顶栏、侧栏、导航和整体壳层体验。

如果你要做的是平台框架外壳，而不是某个具体业务页面，这条路线通常比普通微前端页面更合适。

组件库​

适合给低代码页面补新的可复用控件能力。

如果你不是要替换整页，而是想让业务开发人员在 Schema 页面里直接复用一个自定义组件，优先看组件库。

平台组件库​

适合把一批前端能力稳定分发给多个应用复用，并做版本治理、安装卸载和共享控制。

它解决的不是“单个页面怎么扩展”，而是“这批前端能力怎么以平台级方式被多个应用复用”。

推荐判断顺序​

大多数前端需求，建议按下面顺序判断：

  1. 先判断它属于页面、壳层、页面内复用、跨应用分发，还是门户拼装
  2. 再判断复用范围是单页、单应用，还是多应用
  3. 最后再判断是否真的需要独立前端工程

这套顺序的核心目的是避免一上来就用更重的方式承接更轻的需求。

一张更实用的差异表​

方式主要解决什么不该承接什么
微前端页面复杂页面、独立交互、子系统页面顶栏侧栏壳层、单个低代码控件
自定义登录页登录入口、认证方式组织、品牌化登录体验普通业务页面
布局组件顶栏、侧栏、导航、外壳风格具体业务页面和业务状态编排
组件库低代码页面中的复用控件整页业务流程、平台级分发治理
平台组件库多应用共享和版本治理单一页面内的一次性控件
工作台 / Widget首页、看板、仪表板、入口拼装独立复杂子系统页面

不要混用交付方式​

因为它们服务的是不同层次：

  1. 微前端页面解决“页面级承载”
  2. 自定义登录页解决“登录入口与认证体验”
  3. 布局组件解决“平台壳层”
  4. 组件库解决“低代码页面内的复用控件能力”
  5. 平台组件库解决“多应用分发和治理”

如果一开始边界不清，后面很容易出现：

  • 页面逻辑塞进布局
  • 组件库承担整页职责
  • 平台组件库承担单页一次性逻辑
  • 登录页实现和普通页面实现混在一起
  • 微前端工程职责越来越失控

一条常见实施顺序​

大多数前端扩展，都建议按下面顺序推进：

  1. 先判断需求属于页面、登录、布局还是组件
  2. 再完成 应用改造
  3. 把前端工程打包成可挂载产物
  4. 在平台中上传对应微前端包
  5. 再去做页面覆盖、登录入口替换、布局替换、组件注册或平台级分发

这里最关键的是：先把“可被基座稳定加载”解决，再去做业务层实现。

几类常见组合方式​

组合一：微前端页面 + 业务模型页面覆盖​

适合某个业务对象只有少量页面超出标准能力的场景。

这时不必推翻整个低代码主线，只需要在对应入口上覆盖页面实现。

组合二：自定义登录页 + 微前端应用​

适合既要统一认证体验，又已经采用微前端体系的团队。

登录页只是入口的特殊场景，底层接入方式仍然沿用微前端能力。

组合三：布局组件 + 微前端页面​

适合既要重做平台壳层，又要做复杂业务页面的场景。

布局组件负责外壳，微前端页面负责具体业务界面，两者不要互相越界。

组合四：组件库 + 低代码页面​

适合大部分页面仍留在低代码里，但少量控件需要增强的场景。

这通常比直接把整页切到微前端更稳，也更容易让业务开发人员继续接手。

组合五：平台组件库 + 多应用复用​

适合你们已经明确一批前端能力会在多个应用间长期共享，希望统一安装、升级和回滚。

这时平台组件库负责能力分发，具体页面仍然可以按微前端、布局组件或组件库三条路线分别承接。

一个很实用的边界原则​

微前端页面不是默认答案​

如果只是补一个低代码控件，优先看组件库。

布局组件不应该承接业务页面​

壳层负责壳层，业务内容仍应留在页面入口内。

平台组件库不是单页复用的默认答案​

如果只是单个应用里多页复用，先看组件库；只有跨应用复用、版本治理和平台分发都成立时，再升级到平台组件库。

登录页要单独看​

登录页虽然也是微前端，但它和普通页面相比，多了一层认证链路、provider 组织和 token/i18n 接入边界。

什么时候还不需要写前端扩展​

  • 页面仍然是标准列表、表单、详情、审批页
  • 只是结构化页面的小范围展示调整
  • UI Schema 已经能承接页面改动
  • Widget 或平台组件库已经能满足场景

这时通常应先回到低代码或平台内建能力，而不是直接开前端工程。

常见误选提醒​

  • 要改顶栏菜单样式，不要先起整页微前端，先看布局组件
  • 要补一个表单控件，不要先做平台组件库，先看组件库
  • 要做首页门户，不要默认起子应用，先看工作台和 Widget
  • 要做跨应用复用，不要只靠复制代码，优先评估平台组件库

推荐阅读顺序​

  1. 自定义登录页与认证接入
  2. 微前端应用
  3. 应用改造
  4. 布局组件
  5. 组件库
  6. 工作台、Widget 与平台组件库

下一步看哪里​