微前端全面解析 🔥 重点

巨石应用（Monolith SPA）的三大痛点

1. 开发协作难：200 人改同一个仓库，冲突不断、发布互相阻塞，一个模块出问题全站挂。
2. 技术栈锁定：老系统 AngularJS 想局部用 React 都难，重构要"推倒重来"。
3. 体验割裂：多个独立系统（CRM/ERP/数据平台）各自登录、各自样式，用户来回跳转。

微前端的答案：把一个巨石应用拆成多个独立开发、独立部署、独立技术栈的子应用，由一个基座（主应用）统一加载、路由分发、沙箱隔离。整体体验像一个应用，内部各自自治。

为什么需要沙箱？

子应用在基座里运行，JS 全局变量（window.foo、挂到 window 的库）会互相污染：子应用 A 设置了全局，子应用 B 读到脏数据，卸载 A 后 B 的依赖也没了。

方案 1：快照沙箱（legacySandbox，兼容老浏览器）

class SnapshotSandbox {
  constructor() {
    this.modifiedProps = {};   // 记录改动
    this.active = false;
  }
  active() {
    // 激活时：把 window 现状存快照
    this.windowSnapshot = {};
    for (const key of Object.keys(window)) {
      this.windowSnapshot[key] = window[key];
    }
    // 恢复上次退出时的修改
    Object.keys(this.modifiedProps).forEach(k => { window[k] = this.modifiedProps[k]; });
  }
  inactive() {
    // 退出时：记录修改，还原 window 快照
    for (const key of Object.keys(window)) {
      if (window[key] !== this.windowSnapshot[key]) {
        this.modifiedProps[key] = window[key];   // 存下我改的
        window[key] = this.windowSnapshot[key];  // 还原成原来
      }
    }
  }
}

缺点：切换时全量遍历 window 属性，性能差（几毫秒级可接受但不优雅）。

思路：不碰真实 window，给子应用一个"虚拟 window"

class ProxySandbox {
  constructor() {
    const proxy = window;   // 最终会替换为 fakeWindow
    this.fakeWindow = {};
    this.active = true;
    // 拦截所有属性的读写：读不到时查真实 window，写入进 fakeWindow
    const target = {};
    return new Proxy(target, {
      get(_, key) {
        // 先从 fake 找，找不到回退真实 window
        if (key in target) return target[key];
        return window[key];
      },
      set(_, key, value) {
        target[key] = value;   // 子应用的全局变量写进"自己的沙箱"
        return true;
      },
    });
  }
}
// 子应用代码里 window.a = 1 —— 实际写到沙箱 target，不影响真实 window
// 卸载子应用时整个 proxy 丢弃，零残留 —— 这是 Proxy 沙箱完胜快照的原因

问题：子应用 A 的 body { color: red } 会污染基座和子应用 B

方案 1：scoped（约定 + 编译期加前缀，qiankun 实验性）

// 编译期：给所有选择器加应用前缀（或约定子应用只写带前缀的类名）
// .btn {} → .app-a .btn {}
// 缺点：漏网之鱼（body/全局样式）仍会泄漏，需配合约定

方案 2：Shadow DOM（micro-app / wujie 用）—— 真隔离

const host = document.createElement('micro-app-a');
const shadow = host.attachShadow({ mode: 'open' });
shadow.innerHTML = `<style>.btn{color:red}</style><div class="btn">A 应用</div>`;
// shadow 内的样式与外部完全隔离，外部选不中里面，里面选不中外面
// 缺点：弹层/全局类库（如 antd modal 挂 body 下）会逃出 shadow，需要挂载点处理

方案 3：动态样式处理（qiankun 常用）—— 卸载时移除 style 标签

子应用挂载时把它的 <style> 统一收集，卸载时移除，激活时重新注入 —— 避免"脏样式"累积。仍无法阻止运行时互相影响，所以实践上常配 scoped。

背景

公司有三个独立系统：CRM（Vue2）、数据平台（React18）、审批流（老 jQuery）。员工每天切换登录、跳转体验割裂。目标是：统一登录、统一导航、整体像"一个工作台"，但不重写任何老系统。

方案（qiankun 基座）

1. 新写一个"工作台"基座（React + antd），左侧统一导航，顶部统一用户信息
2. 三个老系统改造 entry 为 UMD 导出生命周期（bootstrap/mount/unmount），其余代码零改动
3. 路由分发：/crm/* 挂 CRM，/data/* 挂数据平台，/approve/* 挂审批流
4. 登录态：基座统一登录拿 token，通过 props 传给子应用，子应用删除各自登录页

// 老系统（Vue2 CRM）改造的最小改动：main.js 加三行
import { createApp } from 'vue';
import App from './App.vue';

let app = null;
export async function bootstrap() {}   // 生命周期①
export async function mount(props) {      // 生命周期②：基座调用
  app = createApp(App).mount(props.container.querySelector('#app'));
}
export async function unmount() {          // 生命周期③：切走时销毁
  app.$destroy(); app = null;
}

结果与复盘

• 1 个月完成整合，三个老系统代码零重写，上线后员工单点登录，工作台日均使用率 +35%
• 复盘：最痛的三个坑 —— ① 老系统全局样式污染基座（用动态 style 收集 + 卸载移除解决）；② CRM 用了 window.Vue 全局变量（Proxy 沙箱拦截后需在沙箱内提供）；③ 弹层组件挂载点需统一配置

要求（用 qiankun 或 micro-app）

1. 基座（React）：左侧菜单，路由分发 /app1/* 和 /app2/*
2. 子应用 1（Vue3）：商品管理页；子应用 2（React）：订单管理页（技术栈异构！）
3. 基座给子应用传登录用户信息，子应用展示在页头
4. 两个子应用各写一条"裸选择器全局样式"，验证隔离是否生效

通关标准

• 两个子应用可独立启动、独立部署，也能在基座内正常切换
• 切走子应用后 console 无报错、无全局变量残留（window.__test 验证）
• 能口头讲清：Proxy 沙箱原理、样式隔离三种方案、四方案选型依据