最近一段时间在学习微前端，一开始是看各种博客了解微前端含义、对比多种微前端框架优劣，最后选择了qiankun、micro-app、wujie这三种微前端框架进行深入研究、对比。
|---------------|-------|---------|---------|------|
| 微前端框架 | 推出时间 | 官方文档易读性 | 社区讨论活跃度 | 配置难度 |
| Qiankun（蚂蚁） | 2019年 | 中 | 高 | 中 |
| Micro-app（京东） | 2021年 | 高 | 中 | 低 |
| Wujie（腾讯） | 2022年 | 低 | 低 | 高 |
Qiankun：
我研究、配置的第一个微前端是qiankun，根据qiankun官方文档可以成功搭建Vue主子应用以及react子应用，但文档中配置项层级模糊且对应示例比较片面，好在网上博客、文档多。如果注册了某个子应用，但没有启动的话会报错。
Micro-app:
micro-app官方文档描述清晰，配置过程简单，是我花费时间最少的微前端。如果注册了某个子应用但没有启动的话不会报错。
Wujie:
可以说wujie给我最大的感觉是文档混乱、步骤不清晰、容易误导人，网上相关的博客、文档很少，翻来覆去内容都很相似，参考意义不大。花了半天搭建、配置Vue主子应用还是没能成功。
微前端的应用场景：
- 当不同的团队开发同一个应用，所选技术栈不同时；
- 现在大型的互联网公司都会为用户提供很多应用和服务，通过微前端可以将多个前端聚合在一起，为用户呈现一站式服务的应用聚合应用。
- 需要保持技术栈不落后，就需要在兼容原有系统的同时，使用新框架去开发新功能，而遗留系统的功能已经足够完善且运行稳定，此时没有必要使用新的框架去重构遗留系统；
- 某个模块可以被多个项目之间共用；
- 为了使系统可以更快速地从故障中恢复或者不因为其中一个模块影响全局。
使用微前端的优缺点：
- 如果一个项目很大，我们更改了一部分代码，到发布的时候，就不用整个项目重新打包编译发布了，可以大大节省时间。还有一种情况：我们需要长时间下架、修改某个模块时，不用专门把这个模块代码去掉，它不会影响其它非相关功能线上正常使用。也意味着可以将故障风险的粒度隔离到更小的范围，更容易排查到问题所在；
- 微前端支持多种前端框架，可以让"新"应用与"旧"应用并行工作，从而提供了一种迁移手段；
- 多个独立的开发团队更容易协同开发单个前端应用，且职责范围更窄，更加易于理解；
- 通信比iframe容易（如可以共享cookie、session），浏览器刷新不用重新加载全部资源且url同步，但它样式隔离不够彻底，可能需要额外调整；
- 各个团队需要建立维护自己的服务器，构建流程和持续集成的管道，可能还加载冗余的js/css，小型项目或者功能简单的项目没有必要用微前端；
- 使用微前端且使用不同数据库的情况下，后端团队有独立的数据库，团队之间需要定期复制数据，一旦出现错误，容易引起数据不一致；
- 使用微前端意味着系统拆分，拆分的粒度越小，维护的成本越高；并且如果应用不同技术栈，技术栈种类越多，维护的难度越大。