微前端实战

很多微前端方案为了实现运行时组合，强行在浏览器端塞入一套复杂的模块加载机制，导致 Webpack 配置变得像迷宫一样，稍微改个依赖就得全量重新构建。其实现在的现代浏览器已经原生支持了 Import Maps，这意味着我们可以直接利用浏览器的原生能力来实现模块映射，而不需要依赖臃肿的框架。

简单来说，Import Maps 就是一个映射表，告诉浏览器：当代码里出现 import React from "react" 时，实际上应该去哪个 URL 下载这个文件。这种方式不需要自定义运行时，也没有 iframe 的性能损耗，构建产物也更小。

核心原理：浏览器原生的映射表

Import Maps 的本质就是一段 JSON 配置，放在 HTML 的 <script type="importmap"> 标签里。比如下面这段配置：

<script type="importmap">
{
 "imports": {
 "react": "https://esm.sh/[email protected]",
 "@fastflights/search/": "https://assets.fastflights.com/search/"
 }
}
</script>

一旦这段配置加载，页面上所有的 JS 模块在执行 import 时，浏览器会自动完成 URL 替换。这是一个标准的 Web 平台特性，而非某个库发明的黑科技，目前主流浏览器全部支持。

实操：如何通过配置实现自动化管理

在实际工程中，手动维护这个 JSON 表显然不现实。我尝试了 rmc-toolkit 这个工具集，它的逻辑是通过一个清单文件（Manifest）来动态生成这个映射表，从而降低配置成本。

下面是一个典型的配置示例，通过定义命名空间和依赖版本，一次性解决所有微应用的依赖寻址问题：

import { defineManifest } from "@rmc-toolkit/core";

export const manifest = defineManifest({
 namespace: "@fastflights",
 assetsOrigin: "https://assets.fastflights.com",
 externalDepsOrigin: "https://esm.sh",
 externalDeps: [
 { name: "react", version: "19.1.0", peerDeps: false },
 { name: "react-dom/client", version: "19.1.0" },
 ],
 defaultPeerDeps: ["react"],
});

这种方案解决的实际痛点

• 依赖冗余： 在传统的微前端部署中，很容易出现每个子应用都打包一份 React 的情况。使用 Import Maps 后，所有子应用共享同一个 URL 的依赖，实测可以显著减少首屏加载的 JS 体积。
• 构建解耦： 子应用在开发时只需要像往常一样 import "react"，无需在构建阶段将其标记为 external 并手动配置复杂的 CDN 路径，所有的映射逻辑全部下放到运行时的 HTML 层面。
• 部署独立： 团队 A 修改了代码并发布到 assets.fastflights.com/search/ 下，只要更新 Import Map 的版本号，用户刷新页面即可看到更新，无需重新构建主应用。

踩坑经验与注意事项

在实操过程中，有几个细节需要注意，否则很容易在部署阶段卡住：

• 路径结尾的斜杠： 在 Import Maps 中，"@fastflights/search/": "https://.../search/" 这种带斜杠的配置是用于匹配该路径下的所有子模块。如果漏掉了结尾的 /，浏览器将无法正确解析子目录下的深层 import。
• 依赖版本冲突： 虽然可以实现共享，但如果两个子应用强依赖于同一个库的不同主版本（例如 React 17 vs 18），Import Maps 的单映射机制会带来挑战。此时需要通过别名（Alias）在映射表中定义多个版本，例如 "react-17": "..." 和 "react-18": "..."。

这种基于原生 ESM 的微前端架构，把复杂性从“构建时”转移到了“运行时”，让开发者回归到编写标准 JS 的状态，而不是在跟构建工具死磕。