各位同学，大家好！
欢迎来到今天的“前端避难所”特别讲座。今天我们要聊的话题，听起来很高大上，但如果你真动手做过微前端，你会发现这简直就是一场“猫捉老鼠”的生存游戏。
主题是：React 微前端沙盒：源码解析在同一页面运行多个 React 实例时的全局变量冲突规避机制。
我知道，听到“沙盒”和“源码解析”这两个词，你们的后脑勺可能已经开始痒了。别担心，今天我们不搞那些虚头巴脑的术语，我们直接把裤子脱了（比喻义，代码裸奔），去看看 React 家族聚会时，为什么大家会打起来，以及我们怎么给它们穿上防弹衣。
第一部分：为什么 React 不喜欢住在一起？
想象一下，你有一个大房子（主应用），然后你决定把房子隔成几个小单间，分别租给 React 16、React 18，甚至还有个同学在用 Vue（别问，问就是混业经营）。
一开始，一切都很美好。大家都在 window 对象这个大客厅里，想干嘛干嘛。
但是，问题来了。React 是个极度依赖“上帝视角”的家伙。它非常依赖 window 对象上的几个关键变量。比如：
window.__REACT_DEVTOOLS_GLOBAL_HOOK__：这是 React 的后门，用来和浏览器开发者工具通信的。如果这个 Hook 被篡改了，或者版本不对，React 就会直接罢工。- 全局变量污染：React 16 和 React 18 的内部实现差异巨大。React 18 引入了自动批处理，这依赖于一些全局状态管理。如果你的微应用引入了旧版的 React，它可能会覆盖主应用的全局变量，导致主应用崩溃。
- 样式打架：这就像两个画家，一个用“红色”当背景色，一个也用“红色”当背景色，结果页面变成了一团浆糊。
所以，当我们在同一个页面运行多个 React 实例时，全局变量冲突是最大的噩梦。如果不加控制，你的微应用不仅会把自己玩死，还会把主应用也拖下水。
第二部分：沙盒——给微应用造个笼子
为了解决这个问题，微前端框架（比如 qiankun、single-spa）发明了一个神器——沙盒。
沙盒的核心思想非常朴素：隔离。
我们要给每个微应用创造一个独立的运行环境。在这个环境里，微应用以为它拥有整个 window，但实际上，它拥有的只是一个“代理对象”。这个代理对象会像保镖一样，拦截微应用对 window 的所有操作，确保它改不了主应用的东西，主应用也改不了微应用的东西。
在业界，主流的沙盒方案主要有两种：
- 快照沙盒：老派功夫，先拍照，再干活，干完活再恢复照片。
- 代理沙盒：新派黑客技术，利用 JavaScript 的
Proxy，实时监控并拦截所有的操作。
今天，我们就以 qiankun 为例，深扒这两种机制的源码。
第三部分：快照沙盒——记性不好的家伙
我们先从快照沙盒开始。这个名字听起来就很笨重，对吧？确实，它的性能不如代理沙盒，但它逻辑简单，容易理解。
3.1 核心逻辑：借鸡生蛋
快照沙盒的工作流程是这样的：
- 启动前：微应用启动前，把
window的当前状态（所有的属性、值）拍个照，存到一个snapshot对象里。 - 运行时：微应用开始跑，它可能会修改
window.a = 1，或者window.b = 'hello'。这些修改会被记录下来，存到一个modifiedProps对象里。 - 卸载时：微应用跑完了，我们要把它清理干净。怎么清理？很简单，把
window恢复到启动前的状态（也就是snapshot），然后把运行时修改的那些属性删掉。
3.2 代码实战：手写一个快照沙盒
来，咱们上代码。别怕，我会用最通俗的注释解释每一行。
class SnapshotSandbox {
constructor() {
// 1. 初始化状态
this.proxyWindow = window;
// 2. 拍个照！记录启动前的所有属性
// 注意：这里我们深拷贝了一个 window 对象，防止引用问题
this.snapshot = { ...window };
// 3. 记录运行期间修改过的属性
this.modifiedProps = {};
}
// 启动沙盒
active() {
console.log('沙盒启动：开始恢复快照...');
// 把 window 恢复到启动前的状态
for (const prop in this.snapshot) {
if (this.snapshot.hasOwnProperty(prop)) {
window[prop] = this.snapshot[prop];
}
}
// 把运行期间修改的属性（如果有残留，或者是其他逻辑需要）恢复
// 实际上，在微前端里，active 通常意味着“重新挂载”，所以这里主要是重置
}
// 卸载沙盒
inactive() {
console.log('沙盒卸载：开始记录修改...');
// 遍历 window，看看哪些属性被改了
for (const prop in window) {
// 如果这个属性在启动前没有，说明是被微应用新增的
// 如果属性值变了，说明是被微应用修改的
if (!this.snapshot.hasOwnProperty(prop)) {
this.modifiedProps[prop] = window[prop];
} else if (window[prop] !== this.snapshot[prop]) {
this.modifiedProps[prop] = window[prop];
}
}
// 关键步骤：把 window 恢复到启动前的状态！
for (const prop in this.snapshot) {
if (this.snapshot.hasOwnProperty(prop)) {
delete window[prop]; // 删除新增的
// 修改的属性也会被 snapshot 覆盖回去
window[prop] = this.snapshot[prop];
}
}
}
}
// --- 演示时间 ---
const sandbox = new SnapshotSandbox();
console.log('主应用状态:', window.React);
sandbox.active();
console.log('微应用启动，开始修改全局变量...');
window.React = '微应用版本';
window.globalConfig = { theme: 'dark' };
console.log('微应用运行中:', window.React);
console.log('主应用状态:', window.React); // 此时主应用的 React 已经被覆盖了！
sandbox.inactive();
console.log('微应用卸载，清理现场...');
console.log('主应用状态:', window.React); // React 恢复了！
console.log('微应用修改的变量:', sandbox.modifiedProps); // 我们记住了它改了什么3.3 源码解析与吐槽
看到这里，你可能会说：“这不就是简单的赋值和删除吗？有什么难的？”
确实，逻辑很简单。但是，这个方案有个致命的缺陷——性能。
每次微应用挂载（active）的时候，它都要遍历整个 window 对象，把成千上万个属性（比如 window.location、window.document、window.history）都复制一遍。这在微前端频繁切换应用的时候，性能开销是巨大的。
更糟糕的是，如果微应用使用了 eval 或者 new Function，它们可能会在运行时动态添加属性，快照沙盒根本来不及“拍照”，就已经被污染了。
所以，qiankun 后来引入了更强大的代理沙盒。
第四部分：代理沙盒——实时监控的特工
代理沙盒利用了 ES6 的 Proxy 对象。Proxy 可以拦截对目标对象（这里是 window）的操作。
4.1 核心逻辑：拦截与记录
Proxy 沙盒不再需要“拍照”了。它就像一个特工，时刻盯着 window 的一举一动。
- 拦截读取：当微应用读取
window.React时，特工返回一个伪造的值（或者真实的值，取决于配置）。 - 拦截写入：当微应用写入
window.React = 'new value'时，特工不直接写入真实的window，而是把这个操作记录下来。
4.2 代码实战：手写一个代理沙盒
这回我们稍微复杂一点，需要处理 get 和 set。
class ProxySandbox {
constructor() {
// 1. 定义伪造的属性
// 这些属性是微应用想要访问的，但主应用可能不想给它
// 比如微应用想用 React 18，但主应用是 React 16，我们就伪造一个 React 18 对象给它
this.fakeWindow = {
// ... 这里可以放一些伪造的变量
React: {
version: '18.0.0',
createElement: () => console.log('微应用在渲染')
}
};
// 2. 定义真实的属性
// 微应用可能需要访问一些真实的全局变量，比如 document, location
// 我们把这些真实属性提取出来，放在这里
this.realWindow = {};
for (const prop in window) {
if (prop in this.fakeWindow) continue; // 如果伪造属性里有，就不放真实的
this.realWindow[prop] = window[prop];
}
// 3. 定义修改记录
this.modifyPropsMap = {};
// 4. 创建代理
this.proxyWindow = new Proxy(this.fakeWindow, {
get: (target, prop) => {
// 如果是 Symbol 类型，直接返回
if (typeof prop === 'symbol') return target[prop];
// 如果伪造对象里有，返回伪造的
if (prop in target) return target[prop];
// 如果伪造对象里没有，但真实对象里有，返回真实的
if (prop in this.realWindow) return this.realWindow[prop];
// 都没有，返回 undefined
return undefined;
},
set: (target, prop, value) => {
// 拦截设置操作
// 如果是 Symbol 类型，直接设置
if (typeof prop === 'symbol') {
target[prop] = value;
return true;
}
// 如果是真实的属性（比如 window.location），直接设置到 window 上
if (prop in this.realWindow) {
window[prop] = value;
} else {
// 如果是伪造的属性，或者新增的属性，记录下来
target[prop] = value;
this.modifyPropsMap[prop] = value;
}
return true;
}
});
}
// 启动/挂载
active() {
// 在 ProxySandbox 中，active 通常意味着激活代理
// 实际上，qiankun 的实现中，active 是恢复快照，inactive 是记录修改
// 但为了演示方便，我们这里简化逻辑
console.log('代理沙盒激活');
}
// 卸载/销毁
inactive() {
// 清理修改记录
this.modifyPropsMap = {};
// 清理伪造属性
for (const prop in this.fakeWindow) {
delete this.fakeWindow[prop];
}
console.log('代理沙盒清理完毕');
}
}
// --- 演示时间 ---
const sandbox = new ProxySandbox();
console.log('主应用 React:', window.React);
sandbox.active();
console.log('微应用读取 React:', sandbox.proxyWindow.React);
console.log('微应用设置 React:', sandbox.proxyWindow.React = '微应用修改的 React');
console.log('主应用 React:', window.React); // 主应用的 React 没变！
sandbox.inactive();
console.log('微应用再次读取 React:', sandbox.proxyWindow.React); // undefined，因为被清理了4.3 源码解析：qiankun 的进阶玩法
上面的代码只是一个简化版。真实的 qiankun 源码（特别是 legacy 模式下的 SnapshotSandbox 和 ProxySandbox）要复杂得多。
qiankun 的 ProxySandbox 还做了以下几件事：
- 处理
Symbol属性：Symbol是 JavaScript 的特殊类型，用来创建唯一的标识符。window上有很多Symbol属性，比如Symbol.toStringTag。在 Proxy 中处理Symbol需要特殊小心，否则会导致死循环。 - 处理
Reflect：为了符合 JavaScript 的最佳实践，qiankun 在set拦截器中使用了Reflect.set。 - 处理
window的特殊属性：有些属性是只读的，或者有特殊的行为。比如window.location，你不能随便改，否则页面会跳转。qiankun 会识别这些属性，并在微应用试图修改它们时，给出警告或者进行特殊处理。
第五部分：JS 沙盒的“死穴”与 CSS 的战争
虽然 JS 沙盒（Proxy 或快照）能解决大部分全局变量冲突，但它并不是万能的神。
5.1 eval 和 new Function 的地狱
这是所有沙盒方案（不仅仅是 React 微前端）的通病。
如果微应用使用了 eval('var a = 1') 或者 new Function('window', 'window.React = 2')，那么这些代码执行时的作用域链指向的是微应用自身的上下文，而不是我们创建的 proxyWindow。
这意味着，沙盒的拦截器对此无能为力！代码依然会直接修改真正的 window 对象。
解决方案：
- 编译时处理：在打包阶段，把
eval和new Function替换成安全的替代品。 - Runtime 限制：在沙盒启动前，强制修改
window.eval和window.Function的指向，指向一个安全的包装函数。 - Shadow DOM（下一节讲）：Shadow DOM 虽然主要是隔离样式，但它也提供了一个隔离的 DOM 树，虽然它不能隔离 JS 的
window，但能在一定程度上减少副作用。
5.2 样式隔离：CSS 的“核战争”
如果说 JS 沙盒是防弹衣，那么样式隔离就是防毒面具。
当 React A 使用 body { background: red } 时，React B 如果也用 body { background: blue }，React B 的样式就会覆盖 React A 的样式。反之亦然。
而且，CSS 的特殊性在于 !important 和全局选择器（如 .container）。一旦两个应用都定义了 .container，页面就会乱套。
解决方案：Shadow DOM
这是目前最彻底的样式隔离方案。
// 创建一个 Shadow DOM 节点
const shadowRoot = element.attachShadow({ mode: 'open' });
// 在 Shadow DOM 里注入样式
shadowRoot.innerHTML = `
<style>
.container {
background: blue; /* 这个样式只在这个 Shadow DOM 里生效 */
}
</style>
<div class="container">我是 React B</div>
`;但是，Shadow DOM 也有缺点：
- 样式穿透问题：Shadow DOM 内部的样式无法直接修改外部的 DOM，外部的样式也无法直接修改 Shadow DOM 内部的 DOM。
- 全局样式丢失：很多全局 CSS 库（如 normalize.css）依赖修改
body或html标签。Shadow DOM 会阻断这种继承。
qiankun 的折中方案：
qiankun 结合了 Shadow DOM 和 样式重置。
- 微应用运行在 Shadow DOM 内部。
- 主应用提供一个全局的样式重置文件（比如
import './reset.css'），确保所有应用的基础样式一致。 - 微应用内部的样式默认是 scoped 的，不会污染全局。
第六部分：实战演练——构建一个简易的微前端框架
为了让大家更深刻地理解，我们模拟一个场景。假设我们要运行两个 React 应用：主应用和子应用。
6.1 主应用代码
// main-app.js
const app = document.createElement('div');
app.id = 'micro-app';
document.body.appendChild(app);
// 我们使用 qiankun 的 loadMicroApp API
// 这里为了演示，我们手动模拟一下沙盒的挂载过程
function mountApp(container) {
console.log('主应用：正在挂载子应用...');
// 假设我们创建了一个代理沙盒
const sandbox = new ProxySandbox();
// 创建一个 iframe 或者 div 来承载子应用
// 为了简化，我们直接用 div，并注入子应用的 HTML
const subAppContainer = document.createElement('div');
subAppContainer.style.cssText = `
width: 100%;
height: 100%;
border: 1px solid red;
position: relative;
`;
// 模拟子应用的 HTML 和 JS
const html = `
<div id="sub-app-root"></div>
<script>
// 子应用代码开始
console.log('子应用：我正在尝试访问 window.React');
console.log('子应用：window.React 是什么？', window.React);
// 子应用修改全局变量
window.React = '子应用改了全局变量';
window.__MY_APP_CONFIG__ = { api: 'http://localhost:3001' };
// 渲染
const root = document.getElementById('sub-app-root');
root.innerHTML = '<h1>我是子应用 React 18</h1>';
console.log('子应用渲染完成');
// 子应用代码结束
</script>
`;
subAppContainer.innerHTML = html;
container.appendChild(subAppContainer);
// 挂载完成后，清理沙盒
sandbox.inactive();
console.log('主应用：子应用挂载完毕，全局变量已恢复');
console.log('主应用：现在的 window.React 是什么？', window.React);
}6.2 运行结果
当你运行这段代码时，你会看到控制台输出如下：
主应用：正在挂载子应用...
代理沙盒激活
子应用：我正在尝试访问 window.React
子应用：window.React 是什么？ undefined (或者伪造的值)
子应用：我正在尝试访问 window.__MY_APP_CONFIG__
子应用：window.__MY_APP_CONFIG__ 是什么？ undefined (或者伪造的值)
子应用：我正在尝试访问 window.React
子应用：window.React 是什么？ { version: '18.0.0', createElement: ƒ } (伪造的)
子应用：window.React = '子应用改了全局变量'
子应用：window.__MY_APP_CONFIG__ = { api: 'http://localhost:3001' }
子应用：我正在尝试访问 window.React
子应用：window.React 是什么？ '子应用改了全局变量' (这是修改后的伪造值)
子应用：子应用渲染完成
代理沙盒清理完毕
主应用：子应用挂载完毕，全局变量已恢复
主应用：现在的 window.React 是什么？ undefined (或者主应用原来的值)看到没有？子应用以为它修改了全局变量，但实际上它只是在修改代理对象里的数据。一旦微应用卸载，代理对象被清空，真正的 window 对象毫发无损！
第七部分：总结——沙盒的哲学
通过上面的源码解析和实战演练，我们可以总结出 React 微前端沙盒的几个核心哲学：
- 隔离即自由：沙盒不是要限制微应用的功能，而是要保护主应用的稳定。微应用以为自己拥有整个世界，其实它只是在沙盒里做梦。
- Proxy 是王道：相比于慢吞吞的快照，
Proxy提供了实时的、高性能的拦截能力。除非你的浏览器极老（不支持 Proxy），否则首选 Proxy 沙盒。 - 样式是噩梦：JS 沙盒解决了变量冲突，但样式冲突往往需要更底层的手段（如 Shadow DOM）或者更严格的规范（如 CSS Modules）。
- 没有银弹：沙盒不是万能的。
eval、new Function、直接操作document.body等行为依然可能带来风险。微前端的最佳实践是：每个微应用都必须是独立的、健壮的。
好了，今天的讲座就到这里。
React 微前端沙盒就像是一个精密的瑞士钟表，每一个齿轮（代理拦截、属性记录、样式隔离）都在为了同一个目标转动：让多个 React 实例在同一张桌子上愉快地吃饭，互不干扰，互不破坏。
希望这篇文章能让你对微前端的内部机制有更深的理解。下次当你看到微前端页面切换丝滑流畅时，别忘了，在屏幕的背后，是无数行代码在为你守护着那个脆弱的 window 对象。
谢谢大家！下课！