随着公司业务的膨胀，处理业务的系统数量也跟着膨胀，运营人员处理一单业务需要在各个系统之间来回穿梭。 为了使运营人员在一个系统里可以完成所有操作，技术人员必须给出解决方案。
其实 iframe 在 “微前端” 这个概念被喊出来之前一直是整合系统的利器，但它有些不理想的地方具体原因戳这里 why not iframe，现阶段的前端开发必须找到一种替代方案，优雅的解决掉这些问题。
为什么不用 iframe，这几乎是所有微前端方案第一个会被 challenge 的问题。但是大部分微前端方案又不约而同放弃了 iframe 方案，自然是有原因的，并不是为了 "炫技" 或者刻意追求 "特立独行"。
如果不考虑体验问题，iframe 几乎是最完美的微前端解决方案了。
iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。
其实这个问题之前这篇也提到过，这里再单独拿出来回顾一下好了。
- url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
- UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
- 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
- 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
其中有的问题比较好解决(问题1)，有的问题我们可以睁一只眼闭一只眼(问题4)，但有的问题我们则很难解决(问题3)甚至无法解决(问题2)，而这些无法解决的问题恰恰又会给产品带来非常严重的体验问题， 最终导致我们舍弃了 iframe 方案。
为了弥补 iframe 方案的不足，让前端开发更方便的把多个业务系统整合到一起，微前端被提出并实现，目前业界使用的方案基本都是基于蚂蚁金服的 qiankun [乾坤], 有天下大一统的味道.