下面我们从几个方面来看一下微前端到底是什么？
是什么：
微前端是由ThoughtWorks在2016年提出，即将一个完整的应用转变为数个可以独立存在并运行的子模块并聚合到一起到应用
为什么:
为何我们要放弃之前的单页面应用而投向微前端的怀抱呢？主要是由于以下几个原因
- 应用随时间发展愈发臃肿，协作开发困难
- 应用体积过大，导致打包时间过长
- 让子模块可以灵活组合，并且易于对不同客户进行定制，并可以进行单独售卖模块
好处:
宏观角度
- 可以独立部署不同的服务
- 实现子应用间的隔离，即可以混用任何框架进行开发
- 实现自治团队，具备独立迭代和创新的能力,方便多团队同时进行开发
- 对外提供灵活的应用售卖方式
微观角度
- 优化代码打包体积
- 可以快速对子应用进行开发迭代，并像拼积木一样将不同对子应用拼接在一起
- 代码库更小，更内聚、可维护性更高
- 渐进地升级、更新甚至重写部分前端功能成为了可能
不足:
- 需要在开发中运行许多不同的应用来测试完整的应用体验
- 整个应用的版本控制变得复杂
- 多个子应用同时开发时需要频繁切换子应用
- 每个团队都有自己的技术选择，浏览器最终可能需要下载很多框架和重复代码，导致依赖项冗余，增加用户的流量负担
- 微前端的一些实现（特别是嵌入 iframe）可能会导致严重的可访问性问题
是否选择？
微前端并不是银弹，是否选用微前端则要结合当前情景具体分析，当项目较小时并不需要使用微前端，而当我们开发大型项目并且需要较为独立端多个团队来协作开发时，选用微前端则会更好一些。
