微前端这套东西，最真实的价值是“多个团队/多个技术栈能在一个壳里各自发版”。但它的副作用也很明显：大家都跑在同一个 window 里，谁动了全局变量、谁加了个不小心的样式、谁忘了清理定时器，别的应用可能就跟着倒霉。

所以隔离几乎是微前端绕不过去的一关。这篇文章想把三个问题讲清楚：

  • 为什么很多团队不把 iframe 当成默认方案？
  • 不用 iframe 的话，JS 隔离一般怎么做？
  • qiankun 的沙箱、样式隔离大概是什么思路？

为什么需要 JavaScript 隔离？

在微前端架构中，各个子应用通常由不同团队开发，它们可能使用不同的技术栈、框架甚至版本。当多个子应用运行在同一个全局环境中时，会产生以下问题：

  • 全局变量污染：子应用可能会修改全局变量或挂载全局方法，导致其他子应用发生异常。
  • 事件和定时器难清理：全局事件监听、定时器如果不卸载，切应用几次就会叠加成“幽灵回调”。
  • 样式冲突：这不是 JS 隔离本身，但实际项目里几乎总会一起踩（全局选择器、reset、变量名撞车）。

为了避免这些问题，你得想办法把“子应用对全局的影响”控制住：要么给它一个独立运行环境（iframe/Shadow DOM 之类），要么用沙箱把它的读写拦下来。

为什么不选择 iframe 方案？

先说清楚：iframe 不是不能用，甚至它的隔离能力是最强的。但很多团队不把它当默认方案，主要是因为“好隔离”换来了一堆工程上的麻烦。

  1. 性能问题
    iframe 每次加载都会建立一个新的浏览器上下文，会增加内存占用和页面加载时间。多个 iframe 嵌套时，性能开销更明显，不利于整体应用的响应速度。

  2. 通信与数据共享困难
    iframe 之间或 iframe 与宿主页面之间的数据传递通常需要依赖 postMessage 等方式，这种通信方式比直接模块间通信更繁琐且容易出错。微前端往往需要组件化的高效协同，直接使用 JavaScript 模块和共享状态会更顺畅。

  3. 样式和资源隔离问题
    虽然 iframe 可以隔离 CSS，但“统一一套主应用的样式/主题”会变得更麻烦（字体、主题变量、公共组件要怎么共享？）。而不用 iframe 的方案更容易共享一套设计体系。

  4. 开发调试复杂度
    iframe 的嵌套和跨域问题会使调试和监控变得复杂。微前端更倾向于采用独立构建、模块化集成的方式，这样既保证各应用独立运行，也能借助统一的工具链进行调试和打包优化。

总结一下：iframe 是“隔离强但协作成本高”，沙箱方案是“协作方便但隔离要自己兜”。选哪个通常看你的业务更在意哪一头。

主流微前端架构如何实现 JavaScript 隔离

1. 沙箱（Sandbox）技术

沙箱技术是实现 JavaScript 隔离的一种常见手段。通过在子应用中建立沙箱环境，可以确保其对全局对象（如 window、document）的修改不会影响到其他子应用。

利用 ES6 Proxy 可以拦截对全局变量的读写操作，构造一个虚拟的全局对象，使子应用只能在该对象上操作，而不会污染实际的 window 对象。

示例代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
function createSandbox() {
  const fakeWindow = {};
  return new Proxy(window, {
    get(target, prop) {
      // 如果 fakeWindow 中存在该属性，则优先返回它
      if (prop in fakeWindow) {
        return fakeWindow[prop];
      }
      // 否则返回真实 window 上的属性
      return target[prop];
    },
    set(target, prop, value) {
      // 将所有写操作保存到 fakeWindow 中
      fakeWindow[prop] = value;
      return true;
    },
  });
}

const sandbox = createSandbox();
// 在 sandbox 环境下运行子应用代码
sandbox.myGlobalVar = 'Hello Sandbox!';
console.log(window.myGlobalVar); // undefined
console.log(sandbox.myGlobalVar); // "Hello Sandbox!"

这种方式可以将子应用对全局变量的修改限制在沙箱中，从而实现基本的隔离。

2. 模块化加载与动态导入

利用 ES6 模块化特性，微前端应用可以将子应用拆分为独立模块。通过构建工具（如 Webpack、Rollup 或 Vite）进行打包，结合动态导入（dynamic import）技术，可以只加载当前需要的模块，从而避免不必要的全局污染。

示例代码（动态导入）：

1
2
3
4
5
// 动态加载子应用模块
import('./micro-app.js').then(module => {
  // 子应用模块的初始化代码
  module.bootstrap();
});

这种方式可以确保子应用仅在需要时加载，并且其模块作用域与其他子应用相互独立。

3. 运行时隔离（Runtime Isolation）

运行时隔离通过在运行时重写全局对象的访问行为，实现子应用的隔离。常见手段包括：

  • 重写 window 对象：在子应用运行前，将其 window 替换为沙箱对象，拦截所有对全局属性的访问。
  • 利用 Web Worker：虽然主要用于多线程运算，但在某些场景下，可以将子应用运行在 Web Worker 中，实现隔离。

这种方法通常需要较为复杂的实现，并且会增加一定的性能开销，因此在微前端架构中，多数场景会首选 Proxy 沙箱或借助成熟框架实现隔离。

Qiankun 是如何实现 JavaScript 隔离的？

qiankun 的核心思路就是“给每个子应用一个沙箱”，把对 window 的读写拦下来：读优先读沙箱，写只写沙箱，卸载时把沙箱里的改动一起清掉。

基于 Proxy 的沙箱

在现代浏览器中，Qiankun 主要采用基于 ES6 Proxy 的沙箱方案。这种方案的核心思路是利用 Proxy 拦截对全局对象的访问和修改操作，将这些操作限定在沙箱内部。

1. 实现原理

  • 拦截全局变量的访问
    Qiankun 会构造一个 Proxy 对象，包装真实的 window 对象。当子应用试图读取或设置全局变量时，Proxy 会拦截这些操作。如果是读取操作，首先会在沙箱内查找该属性；如果不存在，则回退到真实的 window 上。

  • 隔离全局修改
    对全局变量的写操作都会被定向到沙箱内的一个”虚拟全局对象”，而不是直接修改真实的 window 对象。这意味着子应用对 window 的修改仅在沙箱内部有效，当子应用卸载时，这些修改会被清除，不会对其他子应用或主应用产生影响。

2. 示例代码

下面是一个简化的基于 Proxy 的沙箱示例，用于说明基本原理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
function createSandbox() {
  const sandboxData = {}; // 存放子应用对全局变量的修改

  return new Proxy(window, {
    get(target, prop) {
      // 如果沙箱内已有该属性，则返回沙箱内的值
      if (prop in sandboxData) {
        return sandboxData[prop];
      }
      // 否则返回真实 window 的属性
      return target[prop];
    },
    set(target, prop, value) {
      // 将所有写操作存放在沙箱内，而不修改真实 window
      sandboxData[prop] = value;
      return true;
    },
    has(target, prop) {
      return prop in sandboxData || prop in target;
    }
  });
}

const sandbox = createSandbox();
sandbox.myGlobalVar = 'Hello Qiankun!';
console.log(window.myGlobalVar); // undefined
console.log(sandbox.myGlobalVar); // "Hello Qiankun!"

通过这种方式，子应用在 sandbox 内的所有全局操作都不会泄漏到主应用中。

备选方案：快照沙箱

在不支持 Proxy 的旧浏览器（如 IE11）中，Qiankun 则采用了快照沙箱方案。其思路是在子应用启动前，记录当前全局对象的状态；在子应用运行过程中，将所有修改记录下来；而当子应用卸载时，再将全局状态恢复为启动前的状态。这样可以在一定程度上实现全局隔离，但相比 Proxy 沙箱来说，性能和隔离精度可能稍逊一筹。

隔离方案的优缺点

优点

  • 高效隔离：基于 Proxy 的沙箱能实时拦截对全局对象的修改，实现高度隔离。
  • 防止全局污染：子应用对全局变量的修改不会影响主应用和其他子应用，确保系统稳定性。
  • 动态恢复：子应用卸载时可以快速恢复全局环境，不会遗留残余数据。

缺点

  • 兼容性问题：Proxy 沙箱在不支持 Proxy 的旧浏览器中无法使用，需采用快照沙箱，但后者隔离效果和性能不如 Proxy 方案。
  • 实现复杂度：对于部分边缘场景（如跨 iframe 或特殊 DOM 操作），隔离机制仍可能存在细微差异，需额外处理。

Qiankun 如何做样式隔离？

基于 Shadow DOM的严格样式隔离

严格样式隔离利用浏览器的 Shadow DOM 技术为每个子应用创建独立的 DOM 子树，使其样式和结构都被封装在该 Shadow Root 内部。这样，子应用内部定义的 CSS 规则不会泄露到全局，也不会受到外部样式的干扰，从而实现真正的隔离。

在 Qiankun 的启动配置中，可以开启严格样式隔离：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import { registerMicroApps, start, setDefaultMountApp } from 'qiankun';

// 注册子应用
registerMicroApps([
  {
    name: 'micro-app',
    entry: '//localhost:7100',
    container: '#micro-container',
    activeRule: '/micro-app',
  },
]);

// 设置默认挂载应用
setDefaultMountApp('/micro-app');

// 启动 qiankun，并启用严格样式隔离
start({
  sandbox: {
    strictStyleIsolation: true,
  },
});

在上述配置中，设置 sandbox.strictStyleIsolation 为 true 后，Qiankun 会在挂载子应用时将其根容器替换为 Shadow Root，这样子应用的所有样式都被限定在这个 Shadow DOM 内部。例如，子应用原本在全局作用域定义的样式只会在其 Shadow DOM 内起作用，而不会影响主应用或其他子应用。

优点与局限

  • 优点：

    • 完全隔离：真正做到样式和 DOM 的双重封装，避免全局冲突。

    • 原生支持：依赖浏览器内置的 Shadow DOM，不需要额外处理样式重写。

  • 局限：

    • 兼容性：旧版浏览器（如 IE11）不支持 Shadow DOM，需要降级处理。

    • 弹窗或全局组件：某些 UI 组件（例如挂载在 document.body 的弹窗）可能无法直接应用 Shadow DOM 隔离，需要额外处理。

实验性样式隔离 – 基于样式前缀重写

当严格样式隔离因兼容性或业务需求无法采用时，Qiankun 提供了实验性样式隔离方案。该方案通过动态修改子应用中的 CSS 选择器，为其添加一个独特的前缀（通常是一个标识属性或类名），从而使子应用的样式只在特定 DOM 范围内生效。

实验性隔离方案会将所有选择器重写，添加前缀（如 [qiankun-child]）：

1
2
3
4
5
6
7
8
9
/* 原始样式 */
.btn {
  color: red;
}

/* 重写后样式 */
[qiankun-child] .btn {
  color: red;
}

这种重写可以通过如下简化的示例代码实现（仅作演示）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function transformCSS(cssString, prefix = '[qiankun-child]') {
  // 简单示例：为每个选择器前加上前缀
  return cssString.replace(/(^|\})(\s*[^{]+)/g, (match, p1, selectors) => {
    // 分割多个选择器并添加前缀
    const newSelectors = selectors
      .split(',')
      .map(s => `${prefix} ${s.trim()}`)
      .join(', ');
    return `${p1} ${newSelectors}`;
  });
}

const originalCSS = `.btn { color: red; }`;
const transformedCSS = transformCSS(originalCSS);
console.log(transformedCSS);
// 输出：[qiankun-child] .btn { color: red; }

在实际项目中，Qiankun 会自动解析子应用的 CSS，重写其中的选择器，然后注入经过转换的样式表，确保子应用样式仅在其容器内部生效。

配置示例:

在 Qiankun 中，启用实验性样式隔离非常简单，只需在启动配置中设置对应选项：

1
2
3
4
5
start({
  sandbox: {
    experimentalStyleIsolation: true,
  },
});

当配置 experimentalStyleIsolation 后，Qiankun 会为每个子应用的根元素添加一个标识符（例如 qiankun-child 属性或一个特定的 class），并在加载子应用时自动对 CSS 选择器进行前缀重写。

优点与局限

  • 优点：

    • 兼容性好：无需依赖 Shadow DOM，适用于所有现代浏览器，包括部分不支持 Shadow DOM 的环境。

    • 灵活性高：可以在不破坏全局样式的前提下，实现子应用样式的隔离。

  • 局限：

    • 重写复杂性：对于复杂的 CSS 选择器，自动重写可能会出现细微差异，需进行充分测试。

    • 权重问题：前缀重写后的 CSS 可能会因为选择器权重变化而需要额外调整，确保样式正确应用。

如果你正在落地 qiankun 这类方案，我建议你在项目里提前定几条“硬规矩”：子应用卸载必须清理事件/定时器；禁止随手往 window 上挂东西；样式要么隔离、要么有命名规范。隔离做得越早，后面踩坑越少。

Happy Coding!