微前端优缺点及应用场景

本文转载自 知乎-深海潜水员，如需转载，请注明来源

任意一个方案都有优缺点，也不可能适用于所有场景。是否合适的评判唯一标准是收益要大于损失。

为了说明微前端优缺点，把微前端与其他两种方案做对比结果如下。一种是规模化应用也就是巨型单体项目，另外一种是通过nginx实现根据模块区分的应用项目叫模块化项目，特点是跳转其他应用需要重新加载，并产生白屏。

	模块应用	规模化应用	微前端应用
难易度	低	低	中高
可维护性	高	低	高
性能	低	高	中高
用户体验	低	高	高
项目规模	小	小	大
应用场景	移动端、管理端	移动端、管理端	移动端少、管理端多

上图中选了多个维度对比，每个维度的评价高低只是大体准确的，具体还是要分项目类型、项目变更频率。比如说项目本身重要性不高，使用规模化应用最合适。还有一些工具类比如代码编辑器类型的项目显然是用规模化应用收益会更高。

从难易度上讲，微前端应用对现有项目改动和复杂度不算大，提前是你使用集成好的微前端框架。最后，模块应用和规模化应用难易度都相对较低，应该都很熟悉它们。

在性能上，规模化应用性能一定是最好的。原因很简单，用户使用期内，只加载一次框架库并执行一次框架库。微前端首先是需要加载微前端库的，指定跳转的子应用入口也必须加载，并且执行一次子应用框架库。 但微前端好处是，当第二次再调用子应用，有了缓存后则不需要执行。对比规模化应用，微前端性能上略有差距，但在体验上基本可以做到一样。模块应用因为是页面跳转，所有资源都需要重新加载并执行，在性能和体验上都很差。

应用场景上，一般微前端还是应用在管理端，移动端应用比较少。 主要原因是移动端应用一般不会特别复杂。例外也是有的，属于偏工具类的，比如办理贷款的客户经理端项目等。

如果真想使用微前端实现移动或pc端门户类项目，推荐使用微前端具有同构功能方案如Isomorphic Layout Composer，能满足正常门户类项目的性能要求。但也有其他例外情况，如只内嵌在App中，打开app时做好提前预加载微前端应用，也是可以的。

附带讲一下，如果微前端应用在移动端，因为应用的比较少，可能会有一些系统bug没有发现，但也应该不会多。我使用使用qiankun一套框架实现微前端的，也只遇到了这样的一个问题：在老系统ios12系统中，遇到错误导致白屏，qiankun官方很快就处理了，非常赞，看了一下改动，可能不一定行。但暂时没有老手机还没验证，后面验证一下，有结果了再反馈给大家。如果大家遇到类似问题，类似于以上的修改也是比较容易的。如果框架有问题，推荐大家给官方提issue，造福他人。