- 微前端不一定是一种新技术，也不必太复杂。只要我们保证代码隔离和团队自治，无论我们采用何种技术栈，我们都可以达到相同的效果
- 工程越来越大，打包越来越慢
- 团队人员多，产品功能复杂，代码冲突频繁、影响面大
- 在后端服务开发中，为了解决庞大的一整块后端服务带来的变更与扩展方面的限制，出现了微服务架构
- 把应用程序设计成一系列松耦合的细粒度服务
- 允许使用不同的编程语言来编写不同服务
- 前端也出现这样的问题，即，一种由独立交付的多个应用组成整体的架构风格。将前端应用分解成一些更小更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品
- 比起一整块的前端代码库，微前端架构下的代码库倾向于更小/简单、更容易开发
- 传统开发的缺点
- 历史项目，祖传代码
- 交付压力，当时求快
- 就近就熟，当时求稳
- 导致技术栈落后，甚至强行混用多种技术栈，耦合混乱，不敢动，牵一发动全身
每个微前端都应具备有自己的持续交付流水线（包括构建、测试并部署到生产环境），且要能独立部署，不必过多考虑其它代码库的状态
- 技术栈无关，主框架不限制接入应用的技术栈，微应用具备完全自主权
- 独立开发、独立部署，微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
- 增量升级，在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
- 独立运行时，每个微应用之间状态隔离，运行时状态不共享
- 微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。
- 将每个微前端发布为一个 npm 包，并让容器应用程序将所有微前端应用作为依赖项
- 这意味着只要有一个包更新，即使是小版本，宿主也要重新构建一次。不建议使用这种方案
- 优点：隔离得很彻底
- 缺点：速度慢，浏览器处理 iframe 要启动更多的进程；页面刷新难以保存状态，路由、历史记录等等
- 独立构建的 JavaScript 文件可能导致重复的公共依赖，从而增加用户的下载量
- 例如，如果每个微应用都包括自己的 React 副本，那么用户就得多次下载 React
- 在本地开发时无法把所有微应用和对应的后端都启动起来，不得不在本地进行环境的简化。
- 如果开发环境和生产环境不严谨一致，容易造成问题。如果开发者想要完全模拟生产环境，会比较耗时
- 要管理更多的东西：更多的代码库、更多的工具、更多的构建管道、更多的服务器、更多的域名等
