微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
特点
将网站或Web应用程序视为由独立团队拥有的功能的组合。每个团队都有自己关心和专长的不同业务或任务领域。一个团队具有跨职能，并且从数据库到用户界面，端到端地开发其功能。
核心思想
技术栈无关
- 微前端的核心价值在于 “技术栈无关”，这才是它诞生的理由，或者说这才是能说服我采用微前端方案的理由。
独立开发、独立部署
增量升级
建立团队前缀
优于自定义API的本机浏览器功能
建立弹性站点
解决了什么问题
可控体系下的前端协同开发问题（含空间分离带来的协作和时间延续带来的升级维护）
解构巨石应用
避免巨石应用随着技术更迭、产品升级、人员流动带来的工程上的问题
带来了什么价值
产品的组合能力
widget 的产品输出能力
主要还是工程上的价值，产品能力只是其延伸
微前端的架构姿势
核心原则：技术栈无关！！！
- 具体来讲：应用之间不应该有任何直接或间接的技术栈、依赖、以及实现上的耦合
架构目标
- 方案上跟使用 iframe 做微前端一样简单，同时又解决了 iframe 带来的各种体验上的问题
对比iframe
iframe的特点
- 优点：提供了浏览器原生的硬隔离方案，可以完美解决CSS和JS的隔离问题
- 缺点：隔离性无法被突破，导致应用间上下文无法被共享，以及随之带来的较差的开发体验、产品体验
为什么不用iframe
- url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用
- UI 不同步，DOM 结构不共享
- 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
- 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
如果是widget级别，微前端和业务组件的区别在哪？
采用微前端的核心原因是：技术栈无关！无论是对遗产项目的改造，还是对新项目的架构选择，技术栈无关的前提能让项目可持续发展，易上手、易维护。
最后
事实上如果所有的 web 技术栈能做到统一，所有 library 的升级都能做到向下兼容，我们确实就不需要微前端了