什么是微前端
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
微前端（Micro-Frontends）是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。
换一种更直观的理解方式：父应用和子应用其实都是独立的前端项目，父应用可以在内部引入子应用，子应用也可以在自己内部继续引入孙子应用，以此类推。当应用能够作为子应用被其它应用引入的时候，它就成为了我们所说的微应用。
优点
微前端架构具备以下几个核心价值：
● 技术栈无关
主框架不限制接入应用的技术栈，微应用具备完全自主权
● 独立开发、独立部署
微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
● 增量升级
在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
● 独立运行时
每个微应用之间状态隔离，运行时状态不共享
微前端解决了什么问题？
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。比如：
● 原本一个团队管理的项目，后面多个团队进行管理
● 随着项目的体积变大，编译的速度变长，研发效率降低
● 项目变大，系统的复杂度也会随之变大，可维护性越来越低，重构成本越来越大
● ...
通过微前端拆分成一个容器应用和多个子应用之后，各个应用能够独立部署，相互之间隔离，从而做到：
● 研发效率提升：多业务线并行开发，团队自治，独立迭代
● 运维风险降级：变更范围缩小
● 技术选择增多：各个应用可以选择更加适合自身的技术栈
● 重构风险降低：低风险局部替换，渐进式完成大规模重构
● ...
为什么不用iframe
如果不考虑体验问题，iframe 几乎是最完美的微前端解决方案了。
iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。
- url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
- UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
- 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
- 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
其中有的问题比较好解决(问题1)，有的问题我们可以睁一只眼闭一只眼(问题4)，但有的问题我们则很难解决(问题3)甚至无法解决(问题2)，而这些无法解决的问题恰恰又会给产品带来非常严重的体验问题， 最终导致我们舍弃了 iframe 方案。
缺点
● 应用的拆分基础依赖于基础设施的构建，一旦大量应用依赖于同一基础设施，那么维护变成了一个挑战。
● 拆分的粒度越小，便意味着架构变得复杂、维护成本变高。
● 技术栈一旦多样化，便意味着技术栈混乱
● 多次加载重复资源，指定跳转的子应用入口也必须加载，并且执行一次子应用框架库。
只要坚持使用一种框架，并利用像 qiankun 这样的协作框架，你就可以通过资源共享和只需下载一次的公共代码来避免大多数性能损失。
标签：浏览器,应用,前端,问题,了解,iframe,隔离 From： https://www.cnblogs.com/dirtycat/p/17508824.html