微前端 2026 落地指南：Module Federation 与沙箱方案的选型

微前端在 2026 年已经过了「要不要用」的阶段，进入「怎么用对」的阶段：模块联邦成为构建期共享的主流方案，运行时沙箱方案（qiankun、wujie、micro-app）在多团队异构场景继续服役。选型错误的代价很高——微前端引入的隔离与通信复杂度，会让一个本不需要它的项目显著变慢。这篇讲清楚什么场景值得用、四种方案怎么选、以及落地时的四个关键决策。

一、先判断：你的问题是不是微前端能解决的

微前端解决的是组织问题，不是技术问题。三个信号说明值得用：

• 多个团队独立开发、独立发版同一个产品（如中台 + 各业务线）；
• 技术栈异构且短期内无法统一（老 Angular 系统与新 React 系统共存）；
• 需要增量迁移：老系统逐模块替换，新旧长期并存。

反过来，如果只是「想让项目拆小一点」，拆模块、拆包、monorepo 就够了——引入微前端只会增加复杂度。

二、四种主流方案对比

选型粗略原则：同一技术栈、追求依赖共享 → Module Federation；异构老系统共存 → 运行时沙箱方案（三者中按团队熟悉度选）。Module Federation 的机制细节见Webpack 官方文档。

三、落地四个关键决策

1. 样式隔离策略：Shadow DOM 最彻底但会困住全局弹层；约定前缀 + CSS Modules 折中。原则是能靠规范解决的不要上重隔离；
2. 公共依赖治理：共享 React/Vue 版本必须由基座统一提供并锁定，子应用擅自升级会直接炸运行时——把共享依赖清单写进 CI 检查；
3. 通信设计：跨应用通信只传「事件 + 数据」，不做引用共享。状态提升到 URL、全局事件总线或独立状态服务，保持子应用可独立运行；
4. 加载性能：子应用预加载 + 缓存（wujie 的保活与预加载是亮点），否则多应用串行加载会让首屏不可接受。

「公共依赖治理」在 Module Federation 下的具体形态——基座单点提供共享依赖，子应用只声明不打包：

// 基座（宿主）：单点提供共享依赖，版本收口
new ModuleFederationPlugin({
  name: "shell",
  remotes: { orders: "orders@/remote/orders/entry.js" },
  shared: {
    react:   { singleton: true, requiredVersion: deps.react },
    "react-dom": { singleton: true, requiredVersion: deps["react-dom"] },
  },
});

// 子应用：只声明共享，不把 React 打进自己的产物
new ModuleFederationPlugin({
  name: "orders",
  exposes: { "./Page": "./src/pages/Orders" },
  shared: { react: { singleton: true }, "react-dom": { singleton: true } },
});

四、最常见的失败模式

微前端项目失败很少败在技术，多数败在边界没切干净：子应用之间互相 import 对方的工具函数、基座深度感知子应用内部状态、路由规则越写越复杂。保持三个纪律：子应用能独立启动独立发版；基座只管「壳」不管业务；跨边界交互全部走显式契约（事件/接口），纳入代码评审检查项。

一句话总结：微前端是组织架构的镜子——团队边界清晰它就清晰，团队边界混乱它就混乱。先用组织问题判断要不要用，再按技术栈与隔离需求选方案。