什么时候才需要它#

一个中台里，订单团队用 Vue、风控团队用 React，却要合成一个后台；各团队要独立开发、独立部署、互不阻塞。这就是微前端的场景——把”巨石应用”拆成可独立交付的”子应用”。

如果只是单团队单技术栈，微前端是过度设计，反而引入一堆通信/样式隔离/版本协调的复杂度。

核心思路：运行时集成#

与”构建时把代码拼一起”不同，微前端在运行时把子应用挂到基座的容器里：

1
基座（主应用）
2
 ├─ 路由 /app/order  → 加载 Order 子应用（独立部署的 JS）
3
 ├─ 路由 /app/risk   → 加载 Risk 子应用（另一技术栈）

子应用各自构建、各自部署，基座按路由决定加载谁。

主流方案#

• qiankun（基于 single-spa）：国内中台常用，提供 JS 沙箱（隔离全局变量）、样式隔离、应用间通信。开箱即用但偏重。
• Module Federation（Webpack 5）：在构建期声明”哪些模块由谁提供”，运行时直接共享依赖，免重复加载。适合同技术栈的模块级复用，更轻。
• Web Components / iframe：iframe 隔离最彻底但通信难、体验割裂；Web Components 标准但生态弱。

必须面对的代价#

• 样式隔离：子应用 CSS 互相污染（用 scoped/Shadow DOM/命名空间）。
• JS 沙箱：全局变量冲突（qiankun 用 proxy 沙箱）。
• 依赖重复：每个子应用都带一份 React，体积翻倍（Module Federation 可缓解）。
• 通信与调试：跨应用状态同步、错误监控定位变复杂。

小结#

• 微前端解决”多团队独立部署、同屏运行”，非单团队标配。
• 思路：基座 + 运行时集成子应用。
• qiankun 重但开箱全，Module Federation 轻但偏同栈。
• 它带来沙箱/样式/依赖/通信的真实复杂度，上之前算清收益。

练习#

1. 列出你所在团队”是否真需要微前端”的判断清单（团队数、技术栈数、部署独立性）。
2. 对比 qiankun 与 Module Federation 在你的场景下的优劣。
3. 设计一个子应用间通信方案（全局 store vs 自定义事件），说明取舍。