章
目
录
乾坤（qiankun）作为一款热门的微前端框架，其中，沙箱隔离机制是保障微应用独立运行的关键，尤其是JS沙箱，在防止微应用之间的代码冲突方面发挥着重要作用。接下来，我们就深入探究一下qiankun中JS沙箱的原理与实现。
一、为什么需要JS沙箱
在实际开发中，我们经常会遇到一些棘手的问题。比如，我之前参与一个JSP项目时，就发现JSON.stringify({name: '张三'})的结果是'"{\\"name\\":\\"张三\\"}"'，而当使用JSON.parse()解析时，得到的竟然还是字符串。经过仔细审查，才发现原来是JSON方法被重写了。
这种情况并非个例，有些插件为了实现特定功能，会重写很多方法。像Vue2为了实现数据监听，重写了Array的一系列方法；single - spa为了监听路由，重写了pushState、replaceState等方法（不过这些重写一般不会影响原API的正常使用）。但像我遇到的JSON方法被重写的情况，就直接影响了原API的执行结果。
qiankun中默认开启了js、window沙箱，这是非常有必要的。它主要通过三种沙箱来实现隔离：SnapshotSandbox、ProxySandbox以及下文会提到的LegacySandbox（原文未详细提及，简单介绍下）。接下来，我们分别深入了解一下这几种沙箱的实现原理。
二、SnapshotSandbox沙箱
（一）SnapshotSandbox沙箱的原理
SnapshotSandbox是针对不支持proxy api的低版本浏览器设计的，它采用快照的形式来实现沙箱隔离。简单来说，就是在微应用加载时，记录下当前window对象的状态（也就是拍个“快照”），当微应用离开时，对比当前window对象和快照的差异，把更改的部分恢复，并记录这些变更；再次进入微应用时，恢复之前记录的变更。
（二）SnapshotSandbox沙箱的代码实现
下面我们结合代码来深入理解一下：
import type { SandBox } from '../interfaces';
import { SandBoxType } from '../interfaces';
// 定义一个函数，用于循环遍历window对象的属性，并对每个属性执行回调函数
function iter(obj: typeof window, callbackFn: (prop: any) => void) {
// 使用for...in循环遍历对象的属性
// eslint-disable-next-line guard-for-in, no-restricted-syntax
for (const prop in obj) {
// 处理兼容性问题，对于clearInterval属性特殊处理
if (obj.hasOwnProperty(prop) || prop === 'clearInterval') {
callbackFn(prop);
}
}
}
/**
* 基于 diff 方式实现的沙箱，用于不支持 Proxy 的低版本浏览器
*/
export default class SnapshotSandbox implements SandBox {
proxy: WindowProxy;
name: string;
type: SandBoxType;
sandboxRunning = true;
private windowSnapshot!: Window;
private modifyPropsMap: Record<any, any> = {};
constructor(name: string) {
this.name = name;
this.proxy = window;
this.type = SandBoxType.Snapshot;
}
// 当微应用激活（初次进入该微应用）时执行
active() {
// 记录当前window的快照
this.windowSnapshot = {} as Window;
iter(window, (prop) => {
this.windowSnapshot[prop] = window[prop];
});
// 恢复之前的变更
Object.keys(this.modifyPropsMap).forEach((p: any) => {
window[p] = this.modifyPropsMap[p];
});
this.sandboxRunning = true;
}
// 当微应用失活（离开微应用）时执行
inactive() {
this.modifyPropsMap = {};
iter(window, (prop) => {
if (window[prop]!== this.windowSnapshot[prop]) {
// 记录变更，恢复环境
this.modifyPropsMap[prop] = window[prop];
window[prop] = this.windowSnapshot[prop];
}
});
if (process.env.NODE_ENV === 'development') {
console.info(`[qiankun:sandbox] ${this.name} origin window restore...`, Object.keys(this.modifyPropsMap));
}
this.sandboxRunning = false;
}
}
在这段代码中：
active方法在微应用首次加载时被调用，它先创建一个空的windowSnapshot对象，然后通过iter函数遍历window对象，将每个属性的值复制到windowSnapshot中，完成当前window状态的记录。接着，恢复之前离开微应用时记录的变更。inactive方法在离开微应用时执行，它先清空modifyPropsMap，然后再次遍历window对象，对比当前属性值和windowSnapshot中的值。如果有差异，就将当前值记录到modifyPropsMap中，并把window对象的属性值恢复为快照中的值。
需要注意的是，快照沙箱只是进行了一层浅拷贝对比。例如，对console对象内部方法的更改可能不会被记录下来，这种情况可能会影响其他子应用。如果有更复杂的需求，开发者可能需要自行记录原本的变更。
三、ProxySandbox沙箱
（一）ProxySandbox沙箱的原理
ProxySandbox是针对支持proxy的浏览器实现的沙箱机制。它的核心原理是利用JavaScript的Proxy对象，创建一个代理对象来拦截对window对象的访问，从而实现对微应用环境的隔离。
（二）ProxySandbox沙箱的简易实现示例
为了更好地理解，我们先来看一个简易版本的实现示例：
const proxy = {}
(function(window) {
// code 部分
console.log(window,window.console, console) // {}, undefined, console {debug: ƒ, error: ƒ, info: ƒ, log: ƒ, warn: ƒ, …}
}(proxy))
在这个示例中，我们创建了一个空对象proxy，并将其作为参数传递给一个立即执行函数。在函数内部，打印window、window.console和console。可以看到，window是一个空对象，window.console是undefined，而console是正常的console对象。这表明，通过这种方式，我们可以在一定程度上模拟一个独立的window环境。
（三）解决兼容性问题与实现真正的隔离
然而，上述示例还存在一些问题，比如如何兼容console的API呢？这就用到了with语句。with语句可以扩展一个语句的作用域链，允许在代码块中直接使用对象的属性和方法，而无需重复引用对象。但需要注意的是，with语句在严格模式下是被禁止使用的，因为它可能会使代码难以理解和维护。
在实际的ProxySandbox实现中，我们可以这样使用with语句：
const proxy = new Proxy(window, {})
(function(window) {
with (proxy) {
// code 部分
console.log(window,window.console, console) // {}, undefined, console {debug: ƒ, error: ƒ, info: ƒ, log: ƒ, warn: ƒ, …}
}
}(proxy))
这样，就解决了使用window全局API并且走代理的问题。但这种简单的代理方式也会污染原本的window对象（被浅拷贝了）。例如：
a = {name: 1, age: 2} {name:1, age:2}
b = new Proxy(a, {}) < Proxy (0bject) {name: 1, age: 2}
b.six =3 <3
a <{name:1, age: 2, six: 3}
可以看到，对代理对象b添加属性，会影响到原对象a。
（四）qiankun中ProxySandbox的具体实现
那么，乾坤中的ProxySandbox是如何实现的呢？
我们来看一下createFakeWindowAPI的代码：
const rawObjectDefineProperty = Object.defineProperty;
function createFakeWindow(globalContext: Window) {
const propertiesWithGetter = new Map<PropertyKey, boolean>();
const fakeWindow = {} as FakeWindow;
Object.getOwnPropertyNames(globalContext)
.filter((p) => {
const descriptor = Object.getOwnPropertyDescriptor(globalContext, p);
return!descriptor?.configurable;
})
.forEach((p) => {
const descriptor = Object.getOwnPropertyDescriptor(globalContext, p);
if (descriptor) {
const hasGetter = Object.prototype.hasOwnProperty.call(descriptor, 'get');
if (
p === 'top' ||
p === 'parent' ||
p ==='self' ||
p === 'window' ||
(process.env.NODE_ENV === 'test' && (p ==='mockTop' || p ==='mockSafariTop'))
) {
descriptor.configurable = true;
if (!hasGetter) {
descriptor.writable = true;
}
}
if (hasGetter) propertiesWithGetter.set(p, true);
rawObjectDefineProperty(fakeWindow, p, Object.freeze(descriptor));
}
});
return {
fakeWindow,
propertiesWithGetter,
};
}
在这段代码中：
- 首先，通过
Object.getOwnPropertyNames获取globalContext（也就是window对象）的所有属性名，并过滤掉那些可配置的属性。 - 然后，对剩下的属性获取其描述符，并根据属性名进行一些特殊处理，比如将
top、parent、self、window等属性设置为可配置的。 - 最后，使用
Object.defineProperty将这些属性定义到fakeWindow对象中，并冻结它们，防止意外修改。
通过这种方式，创建了一个相对独立的fakeWindow对象，实现了一定程度的环境隔离。
在实际应用中，如果在乾坤的一个子应用环境下更改了window原本全局的属性，在子应用中这个属性也会被更改。
这是因为在proxy的get操作中，如果fakeWindow没有该API，还是会从全局的window上获取。至于为什么没有对window上的API进行深拷贝做绝对隔离，大概率是出于性能方面的考虑。
四、关于qiankun沙箱的常见问题解答
（一）import-html-entry中的子应用信息缓存会造成内存泄漏吗？
const styleCache = {};
const scriptCache = {};
const embedHTMLCache = {};
正常情况下，这种缓存不会造成内存泄漏。因为它是随着加载过的子应用数量增长的，并非持续无限制地增长。除非在特殊场景下，比如子应用数量成百上千，并且都在同一个tab页面执行过，才可能出现问题。在一般情况下，开发者可以放心使用。
（二）如果研发团队代码都很标准，是否可以不开启沙箱？
如果团队代码编写非常规范，且不在window对象上放置全局方法，同时注意body、html、:root等相关元素的使用，那么是可以不开启沙箱的。实际上，在正常项目中，也很少会在全局window上放置东西，所以在满足上述条件时，不开启沙箱也是可行的。
通过对qiankun中JS沙箱的深入分析，我们了解了其原理、实现方式以及在实际应用中的一些注意事项。希望这些内容能帮助大家在使用qiankun进行微前端开发时，更好地理解和运用沙箱隔离机制。
