本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 框架和工具
<a name="frameworks-tools"></a>

不乏前端框架，比如 Angular 和 Next.js，但它们中的大多数并不是在创建时考虑微前端的。因此，它们有时缺少应对微前端架构挑战的机制。

## 一般框架注意事项
<a name="framework-general"></a>

本指南的目的不是推荐或比较各个框架。由于多个微前端通常在同一个Web应用程序页面上运行，因此加载和运行时性能是主要关注的问题。选择一个尽可能减少开销的框架很重要。

框架是根据渲染层划分的：
+ 客户端渲染 (CSR)
+ 服务器端渲染 (SSR)

前端架构包括其他功能，例如静态站点生成 (SSG)。但是，SSG 只能执行一次。微前端主要是在运行时组成的，因此 CSR 和 SSR 是主要选项。

**客户端渲染**

对于企业社会责任，有两种流行的选择：
+ 单个 SPA 框架
+ 模块联合

Single SPA 是构成微前端的轻量级选择。它解决了微前端架构中最常见的挑战，例如在同一页面中组合多个微前端并避免依赖冲突。

Module Federation 最初是一个插件，由 webpack 5 提供，它解决了微前端架构中的绝大多数挑战，包括跨不同工件的依赖关系管理。Module Federation 2.0 原生可与 Rspack、webpack、esbuild 配合使用，现在也可以使用。 JavaScript

考虑完全不使用框架。根据 [caniuse.com](https://caniuse.com/usage-table) 的数据，现代浏览器的总体市场份额为98％，它们本身就提供诸如自定义元素之类的功能，它们足以满足微前端应用程序的需求。必要时，将自定义元素与轻量级库结合使用，以解决事件传播、国际化或其他特定问题。

**服务器端渲染**

在SSR方面，两个主要选项更为复杂：
+ 采用诸如 Next.js 之类的现有框架，并应用使用模块联合的微前端原则。
+ 使用 HTML-交换代表微前端的 HTML 片段，并在运行时将这些片段组合over-the-wire 到模板中。这种方法的一个例子是 Podium。