微前端系列：隔离与通信机制

上一篇拆解了微前端的路由分发与应用加载机制。这篇文章，将深入微前端的其他核心原理------隔离（JS 沙箱、样式隔离）与通信机制。

一、为什么需要隔离与通信？

微前端的核心是"分而治之"，但拆分后的子应用并非完全独立，它们运行在同一个浏览器环境中，必然会面临两个核心问题：

++干扰问题：不同子应用的 JS 全局变量、CSS 样式会相互污染，导致异常。++ 比如子应用 A 定义了 window.utils，子应用 B 也定义了同名变量，会覆盖前者；子应用 A 的 .btn 样式会影响子应用 B 的具有相同 classname 的按钮样式。
++交互问题：主应用与子应用、子应用与子应用之间需要协同工作。++比如主应用的用户登录状态需要同步给所有子应用；子应用 A 的商品选择事件需要通知子应用 B 更新购物车。

隔离机制解决"干扰问题"，保证子应用独立运行；通信机制解决"交互问题"，保证子应用高效协同。

二、隔离机制

隔离机制主要分为三类：JS 隔离、CSS 隔离、资源隔离。

1. JS 隔离：沙箱机制的实现原理[^重点]

JS 隔离的核心目标是"隔离全局变量"，让每个子应用的全局变量（如window上的属性）互不影响。

实现 JS 隔离的技术就是"沙箱（Sandbox）"，常见的沙箱实现方案有三种：快照沙箱、代理沙箱、ShadowRealm 沙箱。

方案 1：快照沙箱（Snapshot Sandbox）

♠️ 核心思路：子应用激活时，记录当前全局变量的快照；子应用卸载时，恢复全局变量到快照状态。

核心实现：

► 子应用激活前，遍历window对象，记录所有属性和值（生成快照）；

► 子应用运行时，自由修改全局变量；

► 子应用卸载时，再次遍历window，对比快照，删除子应用新增的属性，恢复被修改的属性。

javascript 复制代码

class SnapshotSandbox {
  constructor() {
    this.snapshot = {}; // 全局变量快照
    this.modifyProps = []; // 子应用修改的全局属性
  }

  // 激活沙箱
  activate() {
    // 生成快照：记录当前window的所有属性
    this.snapshot = {};
    for (const prop in window) {
      if (window.hasOwnProperty(prop)) {
        this.snapshot[prop] = window[prop];
      }
    }
    // 恢复上一次子应用修改的属性（如果有）
    this.modifyProps.forEach((prop) => {
      window[prop] = this.snapshot[prop];
    });
    this.modifyProps = [];
  }

  // 卸载沙箱
  deactivate() {
    // 对比快照，记录修改的属性
    for (const prop in window) {
      if (window.hasOwnProperty(prop)) {
        if (window[prop] !== this.snapshot[prop]) {
          this.modifyProps.push(prop);
          this.snapshot[prop] = window[prop]; // 更新快照，保留修改
          window[prop] = undefined; // 清除子应用新增的属性
        }
      }
    }
  }
}

✔️ 优势：实现简单，兼容性好（支持 IE）；

❗️ 缺点：性能较差（遍历 window 对象耗时），不支持多子应用同时运行（只能串行激活），适合单实例子应用场景。

方案 2：代理沙箱（Proxy Sandbox）

主流微前端框架多数采用此方案（如 Qiankun）。

♠️ 核心思路：为每个子应用创建一个 Proxy(window)，所有对 window 的读写操作被代理到子应用私有上下文。

核心实现：

javascript 复制代码

class ProxySandbox {
  constructor() {
    // 子应用的私有全局变量副本
    this.privateWindow = {};
    // 创建Proxy代理
    this.proxy = new Proxy(window, {
      get: (target, prop) => {
        // 优先读取子应用私有变量，没有则读取真实window
        return this.privateWindow[prop] ?? target[prop];
      },
      set: (target, prop, value) => {
        // 子应用修改的全局变量，存入私有副本
        this.privateWindow[prop] = value;
        return true;
      },
    });
  }

  // 获取代理后的window
  getSandboxWindow() {
    return this.proxy;
  }

  // 卸载沙箱：清空私有变量
  deactivate() {
    this.privateWindow = {};
  }
}

使用方式：子应用运行时，将代码执行环境的 window 替换为代理对象（通过 with 语句或改造子应用打包配置）。

javascript 复制代码

// 子应用代码执行示例
const sandbox = new ProxySandbox();
const sandboxWindow = sandbox.getSandboxWindow();

// 通过with语句将子应用代码的window指向代理对象
with (sandboxWindow) {
  // 子应用代码：这里的window实际上是代理对象
  console.log(window === sandboxWindow); // true
  window.appName = "app-vue"; // 存入私有副本
}

// 其他子应用无法访问appName
console.log(window.appName); // undefined

✔️ 优势：性能好（无需遍历 window），支持多子应用并行运行，隔离效果彻底；

❗️ 缺点：兼容性稍差（支持 ES6+浏览器），需要改造子应用执行环境。

方案 3：ShadowRealm 沙箱（前沿方案）

提案仍处于 Stage-3，浏览器未原生实现，只能通过 polyfill 实现。 -- ShadowRealm 提案

ShadowRealm 是 ES2022 提出的新特性，用于创建独立的 JavaScript 执行环境，不同 ShadowRealm 之间的全局变量完全隔离，无需手动代理。（其是一个独立的全局环境，它拥有自己的全局对象，其中包含一套自己的内部对象与内置方法）

简单使用示例：

javascript 复制代码

// 创建独立的ShadowRealm环境
const realm = new ShadowRealm();

// 在ShadowRealm中执行代码，无法访问主环境的全局变量
realm.evaluate(`
  window.appName = 'app-vue';
  console.log(window.appName); // 'app-vue'
`);

// 主环境无法访问ShadowRealm中的变量
console.log(window.appName); // undefined

✔️ 优势：原生隔离，性能最优，实现简单；

❗️ 缺点：兼容性差，尚未成为通用方案。

三种 JS 沙箱方案对比

方案	兼容性	性能	支持并行运行	适用场景
快照沙箱	好（IE+）	差	否	低版本浏览器、单实例子应用
代理沙箱	中（ES6+）	好	是	现代浏览器、多实例子应用（企业级项目首选）
ShadowRealm 沙箱	差（现代浏览器部分支持）	最优	是	前沿探索、内部系统（不对外）

2. CSS 隔离：避免样式相互污染[^重点]

CSS 隔离的核心目标是"让子应用的样式只作用于自身，不影响主应用和其他子应用"。

常见的实现方案有四种：样式前缀、CSS Modules、Shadow DOM、Scoped CSS。

方案 1：样式前缀（命名空间）

运行时，通过给每个子应用的样式添加唯一前缀，确保样式隔离。

♠️ 核心思路：为每个子应用的所有样式添加唯一的前缀（如子应用名称），通过 CSS 选择器优先级保证样式隔离。

核心实现：

► 子应用开发时，手动为所有样式添加前缀（如.app-ops-btn）；

► 通过构建工具自动添加前缀（如 PostCSS 的postcss-prefixer插件）。

PostCSS 自动添加前缀示例：

javascript 复制代码

// postcss.config.js
module.exports = {
  plugins: [
    require("postcss-prefixer")({
      prefix: "app-ops-", // 子应用唯一前缀
      ignore: ["html", "body"], // 忽略不需要添加前缀的选择器
    }),
  ],
};

转换前	转换后
`.btn { color: red; }`	`.app-ops-btn { color: red; }`

✔️ 优势：实现简单，兼容性好，无需修改子应用架构；

❗️ 缺点：无法完全避免冲突（前缀可能重复），不支持动态生成的样式。

方案 2：CSS Modules

构建时，将样式类名转换为局部作用域的哈希值，确保样式隔离。

♠️ 核心思路：通过构建工具（Webpack、Vite）将 CSS 文件模块化，为每个样式类生成唯一的哈希值，确保样式类名全局唯一。

核心实现：

► 子应用开发时，将所有样式类名添加到对应组件中（如.btn）；

► 通过构建工具自动为样式类名添加唯一哈希值（如.App_btn__3k2dF）。

实现方式（以 Webpack 为例）：

javascript 复制代码

// webpack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          "style-loader",
          {
            loader: "css-loader",
            options: {
              modules: true, // 启用CSS Modules
            },
          },
        ],
      },
    ],
  },
};

使用	编译后

✔️ 优势：隔离效果彻底，样式类名唯一；

❗️ 缺点：需要子应用采用模块化开发，对遗留项目改造成本高。

方案 3：Shadow DOM（原生隔离）

运行时，将子应用的 DOM 树嵌入到 Shadow DOM 容器中，实现样式隔离。

♠️ 核心思路：利用浏览器原生的 Shadow DOM 特性，创建一个封闭的 DOM 树，子应用的样式只作用于 Shadow DOM 内部，外部样式无法穿透。

核心实现：

► 主应用创建 Shadow DOM 容器；

► 将子应用的 DOM 挂载到 Shadow DOM 内部；

► 子应用的样式自动隔离在 Shadow DOM 内部。

javascript 复制代码

// 主应用创建Shadow DOM
function createShadowContainer(containerId) {
  const container = document.getElementById(containerId);
  // 创建Shadow DOM（open表示可通过container.shadowRoot访问）
  const shadowRoot = container.attachShadow({ mode: "open" });
  return shadowRoot;
}

// 子应用挂载到Shadow DOM
const shadowRoot = createShadowContainer("subapp-container");
// 子应用的HTML和CSS
const subAppHtml = `
  <style>
    .btn { color: red; }
  </style>
  <button class="btn">子应用按钮</button>
`;
shadowRoot.innerHTML = subAppHtml;

✔️ 优势：完全隔离，天然防冲突；

❗️ 缺点：兼容性稍差（支持 ES6+浏览器），部分第三方组件可能不兼容 Shadow DOM（如依赖全局样式的组件）。

方案 4：Scoped CSS（Vue 专属）

构建时，为每个组件的样式添加唯一的属性选择器，实现组件级别的样式隔离。

♠️ 核心思路：Vue 的 Scoped CSS 通过为每个组件的样式添加唯一的 data-v-xxx 属性选择器，实现组件级别的样式隔离。微前端中，可让每个 Vue 子应用的根组件添加唯一的 Scoped 属性，实现子应用级隔离。

核心实现：

► 子应用开发时，为每个组件的样式添加唯一的 data-v-xxx 属性选择器（如 .data-ops-root）；

► 构建工具（如 Webpack）自动为样式类名添加 data-v-xxx 属性选择器，确保样式仅作用于当前子应用。

实现方式：

html 复制代码

<!-- 子应用根组件 App.vue -->
<template>
  <div class="data-ops-root">子应用内容</div>
</template>

<style scoped>
/* 自动添加data-v-xxx属性选择器，仅作用于当前子应用 */
.data-ops-root {
  padding: 20px;
}
.btn {
  color: red;
}
</style>

✔️ 优势：Vue 项目原生支持，实现简单；

❗️ 缺点：仅适用于 Vue 子应用，跨框架项目不适用。

各隔离方案对比

方案	兼容性	隔离效果	适用框架	改造成本
样式前缀	好（全浏览器）	一般	所有框架	低
CSS Modules	好（全浏览器）	好	模块化项目	中
Shadow DOM	中（ES6+）	最好	所有框架	中
Scoped CSS	好（全浏览器）	好	仅 Vue	低

3. 资源隔离：避免静态资源冲突

资源隔离主要解决"不同子应用加载同名静态资源（如 icon.png）"的冲突问题。核心方案是 ++"资源路径隔离"++：

► 构建时注入前缀：Webpack 配置 publicPath 为子应用专属路径（如 /ops/）；

► 主应用加载子应用资源时，通过绝对路径加载，避免相对路径导致的资源查找错误径；

► 使用 CDN 部署子应用资源，通过不同的 CDN 路径区分不同子应用的资源。

javascript 复制代码

// Webpack 配置
module.exports = {
  output: {
    publicPath: process.env.NODE_ENV === "production" ? "/ops/" : "/", // 构建时注入前缀
  },
};

三、通信机制

通信机制的核心目标是"实现主应用与子应用、子应用与子应用之间的信息传递"。

方案 1：全局变量通信

♠️ 核心思路：利用 JavaScript 全局对象（window）作为数据载体，主应用在 window 上挂载全局变量 / 方法，子应用读取或修改该全局变量实现通信；
window
主应用
子应用

核心实现：

javascript 复制代码

// 主应用：挂载全局通信数据/方法（挂载到顶层 window，避免被沙箱隔离）
window.GlobalState = {xxx, yyy};

// 子应用A：读取全局变量
window.GlobalState.xxx

// 子应用B：读取全局变量
window.GlobalState.yyy

✔️ 优势：实现简单，无需额外依赖，快速上手；

❗️ 缺点：数据流向不清晰，复杂场景下易出现数据冲突。

方案 2：props 传递（主 → 子）

主应用的方法直接通过 props 注入子应用；qiankun / micro-app 官方推荐的姿势

♠️ 核心思路：主应用在加载子应用时，通过生命周期钩子将需要传递的信息（如用户信息、全局配置）作为 props 传递给子应用。
props
主应用
子应用

核心实现：

► 主应用在注册子应用时，通过 props 字段向子应用传递数据 / 方法；

► 子应用在「生命周期钩子」（mount/render/bootstrap）中接收 props 参数；

► 子应用可调用 props 中的方法向主应用反馈数据（间接实现双向交互），数据仅在子应用激活时传递，卸载后失效。

javascript 复制代码

// 主应用注册子应用时传递props
registerMicroApps([
  {
    name: "ops",
    entry: "http://localhost:8080",
    activeRule: "/ops",
    container: "#subapp-container",
    props: {
      userInfo: { id: 1, name: "李刚" },
      globalConfig: { baseUrl: "http://api.example.com" },
    },
  },
]);

// 子应用在mount钩子中接收props
export async function mount(props) {
  // 接收主应用传递的参数
  console.log("主应用传递的用户信息：", props.userInfo);
  // 将props挂载到子应用全局，方便内部使用
  window.$appProps = props;
  // 初始化子应用
  new Vue({
    render: (h) => h(App),
  }).$mount("#app");
}

✔️ 优势：实现简单，适合主应用向子应用传递初始化信息；

❗️ 缺点：仅支持主 → 子单向通信，子应用向主应用反馈需借助回调方法，不支持子应用之间通信。

方案 3：postMessage（跨应用通用）

wujie 等 iframe 沙箱方案用 iframe.contentWindow.postMessage

♠️核心思路：利用浏览器的postMessageAPI，实现不同应用之间的跨域通信。
子应用A
主应用
子应用B

核心代码实现（主 → 子）：

javascript 复制代码

// 主应用：向子应用发送消息
const subAppWindow = document.querySelector("#subapp-container").contentWindow;
subAppWindow.postMessage(
  { type: "USER_INFO", data: { id: 1, name: "李刚" } },
  "http://localhost:8081" // 子应用的origin，确保安全
);

子应用接收消息：

javascript 复制代码

// 子应用：监听message事件
window.addEventListener("message", (e) => {
  // 验证消息来源，避免恶意消息
  if (e.origin !== "http://localhost:8080") return;
  // 处理不同类型的消息
  switch (e.data.type) {
    case "USER_INFO":
      console.log("收到主应用的用户信息：", e.data.data);
      break;
    default:
      break;
  }
});

✔️ 优势：支持跨域通信，适用所有跨应用场景；

❗️ 缺点：需要手动处理消息类型和来源验证，通信频繁时代码繁琐。

方案 4：自定义事件总线（发布订阅）

无框架依赖，适用于所有场景。如：mitt、eventemitter3

♠️ 核心思路：主应用实现一个全局的事件总线（发布-订阅模式），子应用通过主应用暴露的接口注册事件和触发事件，实现双向通信。
消息中心
子应用A
主应用
子应用B

► 基于「发布 - 订阅模式」创建一个独立的全局通信仓库 （可理解为 "消息中心"），不依赖微前端框架，可单独封装；

► "消息中心"提供 on（订阅消息）、emit（发布消息）、off（取消订阅）三个核心方法；

► 主应用和所有子应用都引入该通信仓库，通过 "订阅 - 发布" 实现跨应用、多方向通信，数据流向可追溯。

全局事件总线实现：

javascript 复制代码

// 主应用：实现事件总线
class EventBus {
  constructor() {
    this.events = {}; // 存储事件订阅者
  }

  // 订阅事件
  on(eventName, callback) {
    if (!this.events[eventName]) {
      this.events[eventName] = [];
    }
    this.events[eventName].push(callback);
  }

  // 发布事件
  emit(eventName, data) {
    if (this.events[eventName]) {
      this.events[eventName].forEach((callback) => callback(data));
    }
  }

  // 取消订阅
  off(eventName, callback) {
    if (this.events[eventName]) {
      this.events[eventName] = this.events[eventName].filter(
        (cb) => cb !== callback
      );
    }
  }
}

// 主应用创建事件总线实例，并挂载到window
window.eventBus = new EventBus();

子应用使用事件总线通信：

javascript 复制代码

// 子应用A：订阅事件（接收消息）
window.eventBus.on("CART_UPDATE", (data) => {
  console.log("购物车更新：", data);
});

// 子应用B：发布事件（发送消息）
window.eventBus.emit("CART_UPDATE", { goodsId: 1, count: 2 });

// 主应用：发布事件（向所有子应用发送消息）
window.eventBus.emit("USER_LOGIN", { id: 1, name: "张三" });

✔️ 优势：实现简单，支持任意方向通信，代码简洁；

❗️ 缺点：事件总线是全局的，需要避免事件名称冲突，子应用卸载时需取消订阅（避免内存泄漏）。

各方案对比

方案	改造成本	支持通信方向	内存泄漏风险
全局变量通信	极低(直接挂载读取 window 变量，无需修改项目架构，代码侵入性极低)	全方向(主↔子、子↔子)	无(全局变量常驻内存，无事件监听残留；但大量数据挂载可能占用全局内存)
Props 传递	较低(主应用修改子应用注册配置，子应用改造生命周期钩子接收 props，无需额外依赖)	主→子（单向主动）(子→主需通过 props 传递的回调方法间接实现)	极低(子应用卸载后框架自动回收 props 相关资源，无残留风险)
postMessage 通信	中等(需手动封装消息类型定义、来源验证、消息解析逻辑；通信频繁时代码繁琐，需处理事件监听销毁)	全方向(主↔子、子↔子，支持跨域跨上下文通信)	中等(若未手动移除 message 事件监听，易导致内存泄漏，尤其 iframe 场景)
自定义事件总线（Pub/Sub）	较低(可直接引入 mitteventemitter3 等轻量级库，主/子应用统一引入即可，代码侵入性低)	全方向(主↔子、子↔子，同域跨域均支持)	较高(子应用卸载时若未手动调用 off 取消订阅，会残留回调函数，导致内存泄漏)

至此，我们已经掌握了微前端的核心理论基础。下一篇，将聚焦「主流微前端框架选型与对比」，深度解析 Single-Spa、Qiankun、Module Federation 等框架的技术特点、适用场景，帮你快速选对适合项目的框架。