微前端-qiankun2.0

为什么不用 iframe，这几乎是所有微前端方案第一个会被 challenge 的问题。但是大部分微前端方案又不约而同放弃了 iframe 方案，自然是有原因的，并不是为了 “炫技” 或者刻意追求 “特立独行”。

如果不考虑体验问题，iframe 几乎是最完美的微前端解决方案了。

iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。

总结为以下几点（不包括全部）：

url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。

其中有的问题比较好解决(问题1)，有的问题我们可以睁一只眼闭一只眼(问题4)，但有的问题我们则很难解决(问题3)甚至无法解决(问题2)，而这些无法解决的问题恰恰又会给产品带来非常严重的体验问题，最终导致我们舍弃了 iframe 方案。

2019 年 6 月，微前端框架 qiankun 正式发布了 1.0 版本，在这一年不到的时间内，我们收获了 4k+ star，收获了来自 single-spa 官方团队的问候，支撑了阿里 200+ 线上应用，也成为社区很多团队选用的微前端解决方案。

qiankun@2.0 带来了一些新能力的同时，只做了很小的 API 调整，1.x 的用户可以很轻松的迁移到 2.x 版本，详细信息见下方升级指南小节。

微前端是最近一年国内前端领域被频繁提及的关键字，虽然它并不是一个全新的领域/技术，但很显然在当今越来越多的前端应用即将步入第 3 个、第 5 个甚至更久的年头的背景下，如何给巨石应用/遗产应用注入新鲜的技术血液已经成为我们不得不正视的问题，而微前端正是解决这类问题的一个非常合适的解决方案。

qiankun 是一个生产可用的微前端框架，它基于 single-spa，具备 js 沙箱、样式隔离、HTML Loader、预加载等微前端系统所需的能力。qiankun 可以用于任意 js 框架，微应用接入像嵌入一个 iframe 系统一样简单。

qiankun 2.0 带来的最大变化便是 qiankun 的定位将由微前端框架转变为微应用加载器。

此前 qiankun 的典型应用场景是 route-based 的控制台应用，做为一个微应用的聚合框架而被使用。

如上图所示，在这种场景下，一个负责聚合与切换的主应用与多个相互独自的微应用一起构成了整个大的微前端应用，一般来说页面上活跃着的也往往只有一个微应用。

而这是微前端的场景之一，在另外一些场景下，你应该可以在同一个页面中，加载多个不同的微应用，每个微应用都是主应用的组成部分或者是提供一些增强能力，这种场景可以说是微应用粒度的前端组件化。

因此，qiankun@2.0 将跳出 route-based 的微前端场景，提供更加通用的微应用加载能力，让用户可以更加自由的组合微应用来搭建产品。

打赏

支付宝

微信

数学基础

微前端-Single-SPA

本文作者：catzillaorz