Notes
Notes /react/16-advanced/02-micro-frontend-governance

微前端治理：样式、路由与通信

一句话结论：微前端架构通过将大型单体前端拆分为多个独立、可部署的应用来提升团队自治和技术异构性，但其成功与否，关键在于如何通过有效的治理策略来解决样式隔离、依赖共享、路由协作和应用间通信等固有挑战。

1. 什么是微前端 (Micro-Frontends - MFE)？

微前端是一种架构风格，其核心思想是将一个大型的、单体的前端应用，拆分为一系列更小、更内聚、可独立开发和部署的“微应用”。这些微应用在用户看来是一个无缝的整体。

解决的问题：

  • 团队自治：每个团队可以独立负责其业务领域（一个或多个微应用），拥有自己的代码库、开发节奏和技术栈。
  • 增量升级：可以逐步地用新技术栈重写老旧系统的一部分，而不是进行高风险的“大爆炸式”重构。
  • 技术异构：允许在同一个应用中并存多个技术栈（如一个微应用用 React，另一个用 Vue）。
  • 更快的构建和部署：每个微应用的 CI/CD 流水线更小、更快。

2. 主流实现方案

A. Webpack Module Federation

Module Federation (模块联邦) 是 Webpack 5 引入的一项革命性功能，也是目前实现微前端的最主流、最优雅的方案。

  • 核心思想：它允许一个 JavaScript 应用在运行时动态地加载另一个独立部署的应用的代码，并共享依赖。
  • 角色：
    • Host (宿主应用)：消费其他微应用的应用框架。
    • Remote (远程应用)：暴露模块给其他应用消费的微应用。
  • 优势：
    • 真正的运行时集成：不同于 iframe，所有组件都运行在同一个 DOM 和 Window 环境下，体验无缝。
    • 高效的依赖共享：可以配置共享的依赖库（如 react, react-dom）。如果 Host 和 Remote 都依赖 React 18，那么 React 18 的代码只会被加载一次。
    • 灵活性：一个应用可以同时是 Host 和 Remote。

示例配置 (webpack.config.js)

// Remote App (e.g., a checkout micro-app)
new ModuleFederationPlugin({
  name: 'checkout',
  filename: 'remoteEntry.js',
  exposes: {
    './CheckoutButton': './src/CheckoutButton', // 暴露 CheckoutButton 组件
  },
  shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
});

// Host App (e.g., the main product page)
new ModuleFederationPlugin({
  name: 'product',
  remotes: {
    checkout: 'checkout@http://localhost:3001/remoteEntry.js', // 引用 Remote App
  },
  shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
});

// In Host App's code
const CheckoutButton = React.lazy(() => import('checkout/CheckoutButton'));

3. 微前端的治理难题与对策

A. 样式隔离

当多个团队的 CSS 被加载到同一个页面时，全局样式冲突几乎是不可避免的。

  • 对策 1: CSS-in-JS：像 Styled-components 或 Emotion 这样的库会为组件生成唯一的类名，天然地提供了作用域隔离。
  • 对策 2: CSS Modules：与 CSS-in-JS 类似，但在构建时生成唯一的类名，没有运行时开销。
  • 对策 3: Tailwind CSS + PostCSS 前缀：如果使用 Tailwind CSS，可以为每个微应用的 CSS 原子类添加一个独特的前缀（如 mfe1-text-blue-500），从而避免冲突。
  • 对策 4: Shadow DOM：创建一个 Shadow Root，将微应用的整个 UI 封装在里面。这是最彻底的隔离方式，但也会带来新的复杂性（如事件冒泡、全局样式穿透）。

B. 路由协作

如何让用户在不同的微应用之间导航，而 URL 保持一致和可预测？

  • 方案：由宿主应用 (Host) 全权管理路由。宿主应用根据 URL 的路径前缀来决定加载哪个微应用。
    • /products/* -> 加载产品微应用
    • /checkout/* -> 加载结账微应用
  • 实现：在宿主应用的 React Router 中配置路由，当匹配到特定路径时，动态加载对应的微应用组件。微应用内部可以有自己的子路由，但它必须在一个由宿主应用提供的基础路径 (basename) 下工作。

C. 应用间通信

虽然我们希望微应用是内聚的，但有时它们之间确实需要通信。

  • 对策 1: 通过 Props/Callbacks (父子通信)：如果宿主应用渲染一个微应用组件，它可以通过 props 将数据和回调函数传递下去。这是最简单、最直接的方式。
  • 对策 2: 自定义事件 (Custom Events)：一个微应用可以通过 window.dispatchEvent 派发一个自定义事件，其他微应用可以监听这个事件。这是一种松耦合的全局通信方式，但难以追踪和管理。
  • 对策 3: 全局状态管理：可以创建一个共享的全局状态模块（如一个 Zustand store），并通过 Module Federation 将其共享。所有微应用都从同一个共享模块中导入 store，从而实现状态同步。这需要非常谨慎地设计，避免滥用导致微应用之间产生强耦合。
  • 对策 4: 通过 URL 状态：将共享的状态反映在 URL 中，所有微应用监听 URL 变化并做出响应。

D. 依赖共享与冲突

  • Module Federation 的 shared 配置：这是解决依赖共享问题的关键。通过将核心库（react, react-dom, styled-components 等）标记为 singleton: true，可以强制所有微应用使用同一个实例，避免版本冲突和重复加载。
  • 版本策略：团队之间需要就共享依赖的版本达成一致。使用 pnpm 或 yarn 的 resolutions 字段可以在 Monorepo 中强制锁定特定依赖的版本。

4. 推荐的开发模式：Monorepo

虽然微应用可以独立部署在不同的仓库中，但在一个 Monorepo 中开发它们会带来巨大的好处：

  • 统一的开发体验：所有微应用都在一个地方，易于管理。
  • 本地链接：通过 pnpm/yarn workspaces，可以轻松地在本地开发和调试依赖于其他本地包的微应用。
  • 原子化变更：需要同时修改多个微应用的变更，可以通过一次 PR 完成。
  • 共享类型：在 Monorepo 中共享 TypeScript 类型定义变得非常简单。

将 Module Federation 与 Monorepo 结合，是目前构建和治理微前端项目的最佳实践。

5. 关联阅读

← RSC/Server Actions 深水区：边界、约束与缓存一致性实时与离线：WebSocket, PWA 与 Service Worker →
cd ..