导读 #

简单了解下微前端的适用场景。

不能说为了微前端，而去微前端。

后台型应用 #

这种应用通常重复率高，公司为降低开发成本，本身会衍生出一些可以复用的东西。或许可以通过 iframe 的形式进行集成，来快速开发降低产研成本。

随着业务增长，复杂度上升。针对于体验优化和性能优化等要求，很可能要对应用进行区域性重构。

重构的方案呢，需要具备以下特性：

• 可以让新增需求不依赖现有项目技术栈，且支持独立部署
• 可以让已有的应用做最少量的改造之后可以集成到现有后台项目，且支持独立部署
• 新业务可以使用新技术栈进行开发，也可以使用老方案进行开发
• 对于性能极差且无法优化的页面，可以考虑逐步进行技术栈重构，重新进行开发。

在集成的过程中，需要有一个主应用，在根据不同条件去切换不同的项目中去，不需要外部链接。此时采用微前端是一个比较合适的技术选型，它具备以下特性：

• SPA体验：微前端可以使应用保持原有的 SPA 体验
• 技术栈自由：可以使用不同的技术栈开发，支持独立部署
• 性能优化：微前端可以通过处理应用资源的去重，应用自身的预加载、预渲染和缓存处理，也可以对已加载的页面进行保活处理，增加了性能优化的手段。
• 解耦重构：重构的时候不影响其他页面运行，减少重构带来的影响

微前端可以降低大型复杂应用的开发、升级、维护以及团队协作的成本。当然，解决历史遗留的难以开发、升级和维护的大型应用，也是使用微前端的一个重要原因。

注意：微前端更多关注于浏览器中如何实现各个模块应用的集成。

业务场景 #

在大型 To B 应用中，业务的体量大，功能多，定制的需求相对较多。应用的开发往往需要具备可配置、可维护、可拓展、可组装以及可升级等特性。

这种情况下使用微前端是一个不错的技术选型。

当然某些情况也并不适合使用微前端：

• 应用业务单一，不存在多个团队并行开发的情况
• 应用功能非常完善，不存在大量新需求开发的可能
• 团队不想花费大量的时间在应用的改造上，仅保持现有应用的稳定性
• 微前端改造成本非常高；
• 团队内开发人员不熟悉微前端，无法应对微前端架构的复杂性

总结 #

同导读中说过的那句话一样，不要为了微前端而去微前端，一定是现有的技术体系真的无法满足开发诉求或者产生无法解决的业务痛点才需要该技术。

学习资料：深入浅出微前端