1. 什么是微前端

微前端简单来说，就是对前端系统进行切分，独立部署

2. 微前端有好处

在过去的开发中，由于业务十分复杂，代码量十分巨大，动不动就几十万，几百万行，代码量，对任何一个没有经验的前端活着经验不足的前端来说，维护和迭代代码，都是一个巨大的压力。

2.1. 降低业务耦合

运用微服务的思想对整个系统进行拆分，能有效的降低单个服务的代码量，减少无关代码对程序员的影响。同时减少由于部分服务更新影响整个系统短暂不可用情况。

2.2. 降低程序员成本 or 降低程序员犯错概率

当对系统拆分后，单个人看的代码量降低，每个人只要负责自己的服务，无需关系其他服务，降低了心智负担，也能更快的理解业务。

2.3 sass和定制化的平衡？

在过去，sass和定制化往往是冲突的。不sass，无法走量，不定制化，不能赚大钱。 二者结合有个很大的问题，客户往往都是针对某个地方专门定制化，而不是对整个系统重新设计，重新开发（最少在最初的时候是这个样子的）。难道每个客户要定制，我们都要重新git一份下来，然后修改要定制的部分？这样做的心智负担是很高的。但如果系统是这样子的：

系统之间不是强耦合的关系，我的系统在设计之初，就微服务化，每个业务（不紧紧可以是业务）都是一个微服务。这样是一个大sass系统。当有某个大客户掏钱，说：我要定制子系统b，这是我经常用的模块，你们的设计太丑了。这时，只需要把子系统bgit下来，根据客户的需求定制化开发，然后把客户的账号的子系统b的地址更新即可。原本的sass系统无变动，新更新的子系统b只作用于当前的需求方，侵入性大大降低。

3. 微前端的缺点

3.1. 提升系统整体复杂度

虽然降低了单独业务的系统复杂度，但由于分布式部署，各各系统的通信，整体链路，都复杂很多。微服务一个很大很大的缺点，发布订阅。你不知道你订阅的消息什么时候会来到。

3.2. 对顶层设计者要求更高

由于服务的拆分，事件的调用机制不再是时间循环，转变为发布订阅，这对整个系统的设计者来说，是一个很痛苦的过程。

3.3. SSR之初

微服务不支持SSR框架