360隔离沙箱会不会中毒（Qiankun原理详解JS沙箱是如何做隔离）
前言
相信大家也知道 qiankun 有 SnapshotSandbox, LegacySandbox 和 ProxySandbox 这些沙箱 ，而它们又可以分为单例和多例两种模式 ，网上也有很多文章对其进行介绍 。
但这些文章的关注点都是沙箱的环境恢复做的事 ，那 JS 的隔离到底是怎么做到的呢？
换个问法 ，当我写 window.a = 1 的时候 ，a 是怎么被挂载到这些 XXXSandbox 上的呢？又或者我直接云修改 window.a = 123 时 ，JS 沙箱到底是怎么隔离这个 a 的呢？
总不能这样吧：
这篇文章就来简单聊聊 qiankun 沙箱那些事 。
复习一下沙箱
这里我们还是稍微复习一下 qiankun 的三大沙箱吧 。
SanpshotSandbox
第一种是快照沙箱 。
它的原理是：把主应用的 window 对象做浅拷贝 ，将 window 的键值对存成一个 Hash Map 。之后无论微应用对 window 做任何改动 ，当要在恢复环境时 ，把这个 Hash Map 又应用到 window 上就可以了 。 大概如下图所示 。
稍微做下小结：
微应用 mount 时 先把上一次记录的变更 modifyPropsMap 应用到微应用的全局 window ，没有则跳过 浅复制主应用的 window key-value 快照 ，用于下次恢复全局环境 微应用 unmount 时 将当前微应用 window 的 key-value 和 快照 的 key-value 进行 Diff ，Diff 出来的结果用于下次恢复微应用环境的依据 将上次快照的 key-value 拷贝到主应用的 window 上 ，以此恢复环境LegacySandbox
上面的 SnapshotSandbox 有一个问题：每次微应用 unmount 时都要对每个属性值做一次 Diff ，类似这样：
如果有 1000 个属性就要对比 1000 次 ，不是那么优雅 。
LegacySandbox 的想法则是 通过监听对 window 的修改来直接记录 Diff 内容 ，因为只要对 window 属性进行设置 ，那么就会有两种情况：
如果是新增属性 ，那么存到 addedMap 里 如果是更新属性 ，那么把原来的键值存到 prevMap ，把新的键值存到 newMap（当然这里的变量名做了简化）
通过 addedMap, prevMap 和 newMap 这三个变量就能反推出微应用以及原来环境的变化 ，qiankun 也能以此作为恢复环境的依据 。
当然这里的监听用到了 ES6 的新语法 Proxy ，不过这里先不展开讨论 ，在之后的系列文章上会会自己手动实现一个简单的沙箱 。
ProxySandbox
前面两种沙箱都是 单例模式 下使用的沙箱 。也即一个页面中只能同时展示一个微应用 ，而且无论是 set 还是 get 依然是直接操作 window 对象 。
在这样单例模式下 ，当微应用修改全局变量时依然会在原来的 window 上做修改 ，因此如果在同一个路由页面下展示多个微应用时 ，依然会有环境变量污染的问题 。
为了避免真实的 window 被污染 ，qiankun 实现了 ProxySandbox 。它的想法是：
把当前 window 的一些原生属性（如document, location等）拷贝出来 ，单独放在一个对象上 ，这个对象也称为 fakeWindow 之后对每个微应用分配一个 fakeWindow 当微应用修改全局变量时： 如果是原生属性 ，则修改全局的 window 如果是原生属性 ，则修改 fakeWindow 里的内容 微应用获取全局变量时： 如果是原生属性 ，则从 window 里拿 如果不是原生属性 ，则优先从 fakeWindow 里获取这样一来连恢复环境都不需要了 ，因为每个微应用都有自己一个环境 ，当在 active 时就给这个微应用分配一个 fakeWindow ，当 inactive 时就把这个 fakeWindow 存起来 ，以便之后再利用 。
隔离原理
看完上面 ，你大概也知道了这些沙箱是怎么恢复环境的 但是 ，回到我们的问题：qiankun 是怎么把 a 和这些沙箱联系起来呢？也即写下 window.a = 1 是怎么做到对 a 变量隔离的呢？
这个逻辑的实现并不在 qiankun 的源码里 ，而是在它所依赖的 import-html-entry 中 ，这里做一下简化：
把上面字符串代码展开来看看：
可以发现这里的代码做了三件事：
把要执行 JS 代码放在一个立即执行函数中 ，且函数入参有 window, self, globalThis 给这个函数 绑定上下文 window.proxy 执行这个函数 ，并 把上面提到的沙箱对象 window.proxy 作为入参分别传入因此 ，当我们在 JS 文件里有 window.a = 1 时 ，实际上会变成：
那么此时 ，window.a 的 window 就不是全局 window 而是 fn 的入参 window 了 。又因为我们把 window.proxy 作为入参传入 ，所以 window.a 实际上为 window.proxy.a = 1 。这也正好解释了 qiankun 的 JS 隔离逻辑 。
XXX is undefined
不知道看完上面的实现 ，你有没有发现问题 。
假如现在代码里有隐式声明或调用全局对象的代码：
当这样调用 add 时 ，上下文 this 则为刚刚绑定的 window.proxy 。由于隐式声明 add 不会自动挂载到 window.proxy 上 ，所以当执行 add ，eval 就会报 add is undefined 。详见 这个 Issue 。
不要觉得这种情况不会发生 ，实际上 ，这还是挺常见的：
老旧的第三方 SDK JS 文件 Webpack 插件引入的 JS 公司网关层自动注入的 JS 等等...我之前就遇到过这种情况：比如下面 Webpack 会注入脚手架定义好的 CDN 资源重试逻辑：
这个问题的解决的方法也很简单：
把代码 a = 1 改成 window.a 添加全局声明 window a这样一来 ，你就得每次打包代码以及发布时执行一个脚本来做这些文本替换 ，非常麻烦 。而京东的新微应用框架 MicroApp 则提供了一套插件系统：
它可以让开发者在执行 JS 前去做代码文本的替换：
如果要对接别的团队的微应用时 ，而且正好他们有 a = 1 这样的代码 ，那么在加载微应用的时候直接修复全局变量的问题 ，不需要通知他们修改 ，也不失为一种策略吧 。
总结
总结一下 ，qiankun 一共有 3 种沙箱：
SnapshotSandbox：记录 window 对象 ，每次 unmount 都要和微应用的环境进行 Diff LegacySandbox：在微应用修改 window.xxx 时直接记录 Diff ，将其用于环境恢复 ProxySandbox：为每个微应用分配一个 fakeWindow ，当微应用操作 window 时 ，其实是在 fakeWindow 上操作要和这些沙箱结合起来使用 ，qiankun 会把要执行的 JS 包裹在立即执行函数中 ，通过绑定上下文和传参的方式来改变 this 和 window 的值 ，让它们指向 window.proxy 沙箱对象 ，最后再用 eval 来执行这个函数 。
以上就是Qiankun原理详解JS沙箱是如何做隔离的详细内容 ，更多关于Qiankun原理JS沙箱隔离的资料请关注本站其它相关文章！
创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！