React 全局变量劫持防御：在微前端沙箱中利用 Proxy 隔离不同 React 版本的全局单例污染

各位同学，大家下午好！

今天我们要聊的是一个让无数前端架构师半夜惊醒、头发大把脱落的话题——微前端里的“版本战争”与全局变量劫持防御。

想象一下，你正在经营一家米其林三星餐厅。这家餐厅有一个巨大的后厨，里面同时掌勺着法式大餐、川菜、日式寿司和西北羊肉泡馍。这听起来很酷对吧？这就是微前端。

但是，问题来了。法式大餐的厨师长（React 18）正在疯狂地往锅里扔“黄油”和“糖”，而川菜厨师长（React 16）却坚信“麻辣”才是正义。如果他们共用一口锅（也就是 window 对象），那这锅汤最后会变成什么？是甜辣咸怪味的生化武器，还是一道名为“兼容性灾难”的黑暗料理？

今天，我们就来聊聊如何用 Proxy 这把“魔法盾牌”，在这个混乱的后厨里，给每个厨师划定专属的领地，防止他们的调料（全局变量）污染彼此的食材。

---

第一部分：那个坐在王座上的“老大哥”——window

在 JavaScript 的世界里，window 对象就是那个坐在王座上的老大哥。它不仅是你的浏览器窗口，它还是你的银行账户、你的身份证、你家的房产证，甚至是你前任的电话簿。

对于 React 来说，它对 window 有着特殊的癖好。

当你安装 React 时，它会做两件事：

1. 在 window 上挂载 React 对象。
2. 在 window 上挂载 ReactDOM 对象。

这本来没问题。但是，React 18 的到来彻底打破了平衡。React 18 引入了 createRoot，改变了渲染机制；React 17 引入了并发特性。这两个版本虽然长得像亲兄弟，但内核完全不同。

如果你的微前端架构里，一个应用用的是 React 16.8，另一个用的是 React 18，当它们共享同一个 window.React 时，会发生什么？

场景重现：
应用 A（React 16）加载完毕，它很高兴地往 window.React 上挂载了一个属性叫 myCoolFeature。
应用 B（React 18）启动了。它发现 window.React.myCoolFeature 不存在，于是它以为这个功能是缺失的，或者它覆盖了这个属性。
结果就是：应用 B 的代码崩溃了，或者表现出了诡异的行为。

更可怕的是，React 内部有一些“黑科技”。比如 window.__REACT_DEVTOOLS_GLOBAL_HOOK__，这是 React 连接开发者工具的钩子。如果这个钩子被错误版本覆盖，你的 Chrome DevTools 就会报错，或者干脆断开连接，让你无法调试。

所以，隔离 是必须的。

---

第二部分：Proxy——现代 JavaScript 的“超级门卫”

在 Proxy 出现之前，我们怎么隔离？我们用 iframe。iframe 确实是个好东西，它给每个页面都配了一个独立的浏览器窗口。但是，iframe 太重了。加载一个 iframe 就像是在你的豪宅里又建了一栋别墅，内存开销巨大，通信成本高得离谱。

我们想要的是：轻量级的、内存中的、原子化的隔离。

这就轮到 ES6 的 Proxy 登场了。Proxy 允许我们定义一个“拦截器”，当你试图访问某个对象的属性时，Proxy 会先拦住你，问一句：“你要干嘛？”。

如果我们要隔离 React，我们可以创建一个 Proxy 对象，它包装了 window。当某个微应用试图访问 window.React 时，Proxy 不让访问真正的全局 window，而是返回给这个微应用一个“克隆版”的 window，这个克隆版里只有属于它的 React。

这就像给每个微应用发了一副墨镜。戴上墨镜后，他们看到的世界是完美的，但戴墨镜的人（浏览器）看到的却是混乱的。

---

第三部分：实战——如何构建一个“React 隔离沙箱”

好了，理论讲完了，让我们撸起袖子，写点代码。

我们的目标是创建一个 ReactSandbox 类。这个类需要做三件事：

1. 备份：保存真实的 window 上关于 React 的所有关键属性（React, ReactDOM, DevTools 等）。
2. 克隆：创建一套空的、干净的对象，作为微应用使用的“假 window”。
3. 拦截：使用 Proxy 监听对 window 的访问，根据属性名决定返回真实的还是克隆的。

3.1 准备工作：识别“敌人”

首先，我们需要知道哪些属性是 React 的“死忠粉”，不能共享。

// 我们需要隔离的 React 全局对象列表
const REACT_GLOBALS = [
  'React',
  'ReactDOM',
  'ReactDOMServer',
  'ReactDOMFiber',
  'ReactDOMFragment',
  'ReactVersion',
  // 还有那些看不见的内部对象
  '__REACT_DEVTOOLS_GLOBAL_HOOK__',
  '__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED',
  '__REACT_DEVTOOLS_EXTENSIONS__',
  '__REACT_CONTEXT_HOOKS__',
  // 等等...
];

class ReactSandbox {
  constructor() {
    // 1. 捡起地上的“真家伙”
    this.realGlobals = {};
    REACT_GLOBALS.forEach(key => {
      this.realGlobals[key] = window[key];
    });

    // 2. 准备“替身演员”
    this.fakeGlobals = {};

    // 3. 开启“魔法护盾”
    this.sandboxWindow = new Proxy({}, {
      get: (target, prop) => this.#handleGet(prop),
      set: (target, prop, value) => this.#handleSet(prop, value),
      has: (target, prop) => this.#handleHas(prop),
      // 还有 deleteProperty, ownKeys 等等，为了严谨我们加上
    });
  }

  // 处理读取操作
  #handleGet(prop) {
    // 如果是 React 相关的全局变量，返回“替身”
    if (REACT_GLOBALS.includes(prop)) {
      return this.fakeGlobals[prop];
    }

    // 如果不是 React 相关的（比如 window.location, window.document），我们要小心处理
    // 通常微应用需要访问 document 和 location，所以我们不能完全屏蔽它们
    // 这里我们采取“保守策略”：如果微应用试图访问 React 的东西，给假的；其他给真的。
    // 或者，我们可以选择完全屏蔽第三方库，只给浏览器原生对象。
    // 在微前端中，通常只隔离第三方库，保留原生对象。
    return window[prop];
  }

  // 处理写入操作
  #handleSet(prop, value) {
    // 这是最关键的！
    // 微应用试图修改 window.React 或 window.ReactDOM。
    // 我们必须拦截，不能让它污染全局！
    if (REACT_GLOBALS.includes(prop)) {
      // 把它存到“替身”里，而不是全局
      this.fakeGlobals[prop] = value;
      // 返回 false，阻止写入全局 window
      return false;
    }

    // 其他属性允许写入（虽然通常不建议在 window 上写东西）
    return true;
  }

  // 处理 in 操作符
  #handleHas(prop) {
    if (REACT_GLOBALS.includes(prop)) {
      // 微应用认为 React 是存在的（因为它有 React 对象）
      return true;
    }
    return prop in window;
  }

  // ... 其他 Proxy 拦截器
}

3.2 初始化“替身”

上面的代码定义了规则，现在我们需要在沙箱启动时，把 React 的实例注入到“替身”里。

假设我们有一个加载器，它负责加载 React 16 的脚本，然后加载应用脚本。

class ReactSandbox {
  // ... 之前的代码

  // 启动沙箱，注入特定版本的 React
  mount(version = '16') {
    // 清理旧的替身
    Object.keys(this.fakeGlobals).forEach(key => delete this.fakeGlobals[key]);

    // 根据 version 决定加载哪个 React
    if (version === '18') {
      // 这里假设你已经通过 importScripts 或 script 标签加载了 React 18
      this.fakeGlobals.React = window.React18; 
      this.fakeGlobals.ReactDOM = window.ReactDOM18;
    } else {
      this.fakeGlobals.React = window.React16;
      this.fakeGlobals.ReactDOM = window.ReactDOM16;
    }

    // 递归处理 React 内部的引用，防止循环依赖导致报错
    this.#recursiveCopy(this.fakeGlobals.React, this.realGlobals.React);
    this.#recursiveCopy(this.fakeGlobals.ReactDOM, this.realGlobals.ReactDOM);
  }

  // 一个递归函数，把真实 React 的属性复制给替身 React
  // 这样微应用就能调用 React 的方法了
  #recursiveCopy(source, target) {
    if (!source || typeof source !== 'object') return;
    for (const key in source) {
      if (source.hasOwnProperty(key)) {
        target[key] = source[key];
      }
    }
  }

  // 获取沙箱的 window
  getSandboxWindow() {
    return this.sandboxWindow;
  }
}

3.3 运行时交互

现在，当微应用运行时，它使用的 window 实际上是我们 Proxy 返回的对象。

// 假设这是微应用的入口代码
function runMicroApp() {
  const sandbox = new ReactSandbox();

  // 模拟加载 React 18
  sandbox.mount('18'); 

  // 获取沙箱提供的 window
  const appWindow = sandbox.getSandboxWindow();

  // 现在，应用以为自己在使用 window.React
  // 实际上，它使用的是沙箱里的 window.React (React 18)
  console.log(appWindow.React); // React 18 实例

  // 尝试修改
  appWindow.React.myCustomHook = 'Hello';

  // 检查全局 window，发现什么都没有！
  console.log(window.React.myCustomHook); // undefined
}

---

第四部分：进阶技巧——处理“循环引用”和“隐藏的 API”

你以为写完上面的代码就完事了吗？天真！React 的内部实现非常狡猾，它喜欢玩“循环引用”的游戏。

如果你只是简单地把 window.React 的属性复制给 fakeGlobals.React，那么当你访问 fakeGlobals.React.createElement 时，它可能会尝试访问 fakeGlobals.React.createElement，这没问题。

但是，如果 React 内部引用了 window.ReactDOM，而我们没有把 fakeGlobals.ReactDOM 传进去，React 就会报错：“Cannot read property ‘Fiber’ of undefined”。

4.1 构建完整的隔离环境

我们需要更智能的初始化逻辑。我们需要确保 fakeGlobals.React 能看到 fakeGlobals.ReactDOM，反之亦然。

class ReactIsolation {
  constructor() {
    this.rawReact = window.React;
    this.rawReactDOM = window.ReactDOM;

    this.fakeReact = {};
    this.fakeReactDOM = {};

    // 预先建立引用关系，防止循环引用丢失
    this.fakeReact.ReactDOM = this.fakeReactDOM;
    this.fakeReactDOM.React = this.fakeReact;

    this.sandboxWindow = new Proxy({}, {
      get: (target, prop) => {
        // 1. 如果是 React 全局对象，返回我们的假对象
        if (prop === 'React') return this.fakeReact;
        if (prop === 'ReactDOM') return this.fakeReactDOM;
        if (prop === 'ReactServer') return this.fakeReactDOM;

        // 2. 如果是其他第三方库（比如 lodash），我们通常也需要隔离
        // 这里简化处理，假设只隔离 React 生态
        return window[prop]; 
      },
      set: (target, prop, value) => {
        // 拦截设置
        if (prop === 'React') {
          this.fakeReact = value;
          return true; 
        }
        if (prop === 'ReactDOM') {
          this.fakeReactDOM = value;
          return true;
        }
        return false;
      }
    });
  }

  // 深度初始化 React 对象
  init(version) {
    if (version === '18') {
      // 这里通常涉及 importScripts 加载外部脚本
      // 我们需要把加载进来的实例挂载到 fakeReact 上
      this.fakeReact = window.React18;
      this.fakeReactDOM = window.ReactDOM18;

      // 关键步骤：递归填充原型链和内部属性
      this.#fillObject(this.fakeReact, this.rawReact);
      this.#fillObject(this.fakeReactDOM, this.rawReactDOM);

    } else {
      this.fakeReact = window.React16;
      this.fakeReactDOM = window.ReactDOM16;
      this.#fillObject(this.fakeReact, this.rawReact);
      this.#fillObject(this.fakeReactDOM, this.rawReactDOM);
    }
  }

  // 递归填充属性，确保微应用能调用 React 的所有方法
  #fillObject(target, source) {
    for (const key in source) {
      if (source.hasOwnProperty(key)) {
        target[key] = source[key];
      }
    }
  }

  getWindow() {
    return this.sandboxWindow;
  }
}

4.2 那个看不见的钩子：__REACT_DEVTOOLS_GLOBAL_HOOK__

React 18 依赖 DevTools。如果你隔离了 window.React，但没有隔离 window.__REACT_DEVTOOLS_GLOBAL_HOOK__，或者隔离错了版本，会发生什么？

现象： 你的 DevTools 里，这个微应用显示为 Unknown，或者点击组件没有任何反应，状态树是空的。

原因： DevTools 会尝试调用 window.__REACT_DEVTOOLS_GLOBAL_HOOK__.render。如果 Hook 是空的，它就不知道怎么渲染。

解决方案： 我们必须把 DevTools 的 Hook 也隔离，并且根据 React 版本选择正确的 Hook。

// 在 ReactIsolation 类中
init(version) {
  // ... 加载 React 的代码 ...

  // 获取 DevTools Hook
  const hook = window.__REACT_DEVTOOLS_GLOBAL_HOOK__;

  if (hook && hook.render) {
    // 拦截 DevTools 的访问
    this.sandboxWindow.__REACT_DEVTOOLS_GLOBAL_HOOK__ = {
      ...hook, // 复制基础方法
      render: (fiber, element, id) => {
        // 这里可以做一些自定义逻辑，比如把 DevTools 的输出重定向到主应用的控制台
        // 或者只是简单地透传
        hook.render(fiber, element, id);
      },
      supportsFiber: true,
      supportsProfilerTimer: true,
      // React 18 新增的属性
      supportsMutableSource: hook.supportsMutableSource || false,
      rendererPackageName: `react-${version}`,
      // ...
    };
  }
}

---

第五部分：Proxy 的“双刃剑”——陷阱与性能

虽然 Proxy 很强大，但用不好就是自寻死路。作为资深专家，我必须告诉你那些坑。

5.1 eval 和 new Function

Proxy 只能拦截“属性访问”（x.y）。它不能拦截 eval('x.y') 或者 new Function('return x.y')。

如果你的微应用代码里写了这样的东西：

eval('window.React.render()');

Proxy 是拦不住的。这段代码依然会去修改全局的 window.React。

防御措施：
微前端框架（如 qiankun）通常会在加载脚本前，把 eval 和 new Function 的引用重定向到一个安全的包装函数，或者直接在沙箱启动前就把 window.eval 设为只读/不可写。

5.2 原生对象 vs. 对象

请注意，我们之前的代码中，对于非 React 的属性（如 window.location），我们直接返回了 window[prop]。

这其实是一个巨大的隐患。如果微应用试图修改 window.location.href，它会直接修改全局的 window.location。

更好的策略：
如果你追求极致的隔离，你应该连 window.location、window.document、window.history 都进行代理。
但这非常复杂，因为浏览器对这些对象有特殊的限制（比如你不能随便改变 location 的属性，否则页面会跳转）。

折中方案：
大多数微前端方案只隔离第三方库（如 React, Vue, Lodash），保留浏览器原生 API（DOM, History, Location）的访问权，但通过限制这些原生对象的修改权限来保护主应用。

get: (target, prop) => {
  if (prop === 'React') return this.fakeReact;

  // 原生对象代理
  const nativeWindow = window;
  if (prop === 'location' || prop === 'document' || prop === 'history') {
    return new Proxy(nativeWindow[prop], {
      set: (t, p, v) => {
        // 严格模式：禁止修改原生对象
        throw new Error(`Cannot modify ${prop} in sandbox`);
      }
    });
  }

  return nativeWindow[prop];
}

5.3 性能损耗

每次微应用访问 window 上的一个属性，Proxy 都要跑一圈 get 函数。虽然现代 JavaScript 引擎对 Proxy 优化得很好，但在高频率调用下（比如 React 每一帧都在渲染），这依然会有微小的开销。

优化建议：
不要代理整个 window。只代理你需要隔离的那几个变量。对于其他 99% 的属性，直接透传，不要走 Proxy。

---

第六部分：微前端架构中的实战应用

现在，让我们把 React 隔离沙箱放入一个完整的微前端生命周期中。

假设我们使用 qiankun（微前端界的扛把子）架构。

6.1 应用加载前

当主应用决定加载子应用时，它会调用子应用的 mount 生命周期。

// 主应用逻辑
export async function mount(props) {
  // 1. 创建沙箱
  const sandbox = new ReactIsolation();

  // 2. 加载子应用资源（React 18 版本）
  await loadScript('https://cdn.example.com/app-v2/entry.js');

  // 3. 初始化沙箱环境
  sandbox.init('18');

  // 4. 获取沙箱的 window，并注入到子应用的上下文中
  // qiankun 通常通过 props 传递 window，或者修改 global variable
  const appWindow = sandbox.getWindow();

  // 在 qiankun 中，我们通常使用 execScripts 来执行子应用的脚本
  // 我们可以在这里把 appWindow 赋值给一个全局变量，或者通过作用域传递
  globalThis.__SANDBOX_WINDOW__ = appWindow;

  // 5. 执行子应用的主入口
  if (window.__APP_MAIN__) {
    window.__APP_MAIN__(appWindow);
  }
}

6.2 子应用内部

子应用代码通常是这样的：

// app-v2/entry.js (打包后的代码)
window.__APP_MAIN__ = (window) => {
  // 子应用现在使用的是沙箱的 window
  // 它以为自己在用 React 18
  const { createRoot } = window.ReactDOM;

  const root = createRoot(document.getElementById('root'));
  root.render(<App />);

  // 如果它尝试修改 window.React
  window.React.myProp = 'test';

  // 这只会修改沙箱里的 window，不会污染主应用！
  console.log(window.React.myProp); // 'test'
  console.log(globalThis.__SANDBOX_WINDOW__.React.myProp); // 'test'
  console.log(window.React.myProp); // undefined (主应用的 window)
};

---

第七部分：总结与反思

讲到这里，相信大家对“React 全局变量劫持防御”有了深刻的理解。

核心要点回顾：

1. 痛点：微前端多版本共存导致 window 对象污染，React 16 和 18 互不相容。
2. 方案：使用 ES6 Proxy 创建一个“中间层”。
3. 实现：拦截 get（读取）和 set（修改），区分 React 相关对象和原生对象。
4. 细节：必须隔离 __REACT_DEVTOOLS_GLOBAL_HOOK__ 和 __SECRET_INTERNALS__，否则调试困难。
5. 局限：Proxy 无法拦截 eval，需要配合其他手段。

最后，我想说：
编程不仅仅是写代码，更是关于控制。在微前端的混乱世界里，Proxy 就是你的控制杆。它允许你在一个混乱的系统里，强行建立秩序。

不要害怕使用高级特性，Proxy 虽然看起来有点“玄学”，但它解决的是架构层面的根本问题。当你看到微前端架构在 Chrome DevTools 里完美运行，每个版本的应用都互不打扰、各自精彩时，你就会明白，这一下午的 Proxy 代码写得是多么值了。

好了，今天的讲座就到这里。希望大家在未来的项目中，都能拥有一把属于自己的“魔法盾牌”，抵御版本污染的洪水猛兽！

下课！