Native Federation 能终结 Module Federation 吗？2025 微前端架构的冷思考

最近社区里关于"浏览器原生 ESM 即将杀死 Webpack Module Federation"的讨论越来越热。支持者拿着 Chrome 团队的 Import Maps 提案和原生依赖共享的理论性能数据，似乎 2025 年就是微前端架构改朝换代的节点。

但如果你在大型代码库里真正维护过微前端应用，可能会对这种"原生崇拜"保持警惕。Import Maps 确实解决了模块解析的底层问题，但把"浏览器支持了"等同于"生产可用"，中间还隔着巨大的工程实践鸿沟。

Module Federation 的"重"与真实价值

先说现状。Webpack Module Federation 被诟病最多的，就是它那几十到上百 KB 的 runtime 开销。每次加载远程模块，都需要先下载并执行 federation runtime，进行复杂的依赖协商和模块映射。

这个 overhead 是真实存在的。在一个典型的中后台微前端场景里，如果采用动态远程加载（dynamic remote），首屏确实会多 1-2 个 RTT（Round-Trip Time）用于获取 remoteEntry.js 并初始化共享作用域。

但代价换来的能力常被忽视：

• 运行时版本协商：当 Shell 应用使用 React 18.2.0，而某个微应用依赖 React 18.1.0 时，Module Federation 能在浏览器里实时决定共享哪个版本，或允许两者并存。这种细粒度的依赖仲裁，目前没有任何原生方案能复现。
• 按需加载与预加载策略：通过 init() 和 get() 的显式 API，开发者可以精确控制远程模块的加载时机，甚至实现基于路由的预加载。
• 构建时解耦：微应用可以独立部署、独立构建，完全不需要知道消费方的存在。

这些能力在大型组织架构下是刚需。简单地把模块换成原生 ESM <script type="module"> 加载，看似减少了 runtime 体积，实际上把版本冲突、循环依赖、加载时序的复杂性直接暴露给了业务开发者。

Native Federation 的"轻"与隐藏成本

Native Federation（或基于 Import Maps 的原生微前端方案）的核心吸引力在于零运行时开销。理论上，浏览器直接通过 import-maps 解析裸导入（bare import specifiers），配合 HTTP/2 的服务器推送或 Early Hints，可以实现比 Module Federation 更纯粹的按需加载。

技术原理简述：

<script type="importmap">
{
  "imports": {
    "react": "https://cdn.example.com/react@18.2.0/esm/index.js",
    "app-dashboard": "https://microapps.example.com/dashboard/entry.js"
  },
  "scopes": {
    "/dashboard/": {
      "react": "https://cdn.example.com/react@18.1.0/esm/index.js"
    }
  }
}
</script>

看起来优雅，但生产环境落地时，以下几个兼容性陷阱往往被乐观估计：

1. Import Maps 的浏览器支持现状

截至 2024 年底，Import Maps 在 Chrome/Edge（89+）、Firefox（108+）、Safari（16.4+）已获得支持。看起来覆盖率不错，但企业级应用往往要兼容 IE11 或旧版 Chrome。

如果为了兼容需要引入 es-module-shims 这类 polyfill，事情就变得微妙了。这个 shim 需要在页面早期注入，拦截所有模块请求，在旧浏览器里用 Fetch API 重新实现模块加载逻辑。实测表明，在低端安卓设备或旧版 Safari 上，polyfill 的解析开销可能抵消甚至超过 Module Federation 的 runtime 成本。

2. CSP（内容安全策略）的噩梦

Module Federation 的动态加载依赖于 eval 或 new Function() 执行远程代码，这在严格 CSP 环境下确实需要配置 unsafe-eval 例外。但 Native Federation 面临的 CSP 挑战更为隐蔽：

• Import Maps 要求 script-src 策略允许内联 JSON（或者外部加载 importmap.json）
• 跨域 ESM 模块需要精确的 CORS 配置，且Access-Control-Allow-Origin不能为通配符*（因为 ESM 请求会携带 credentials）
• 一旦采用外部 CDN 托管共享依赖，需要维护复杂的 script-src 白名单

在金融行业等安全敏感场景，说服安全团队开放这些策略，比说服他们接受 Module Federation 的 runtime 体积要困难得多。

3. 缓存失效的复杂度

Module Federation 通过 content-hash 的 remoteEntry.js 实现了细粒度的缓存控制。每个微应用更新时，只有对应的 entry 和变更 chunk 失效。

而 Native Federation 方案通常依赖 Import Maps 的精确映射。当共享依赖（如 React）升级时，你需要原子性地更新所有微应用的 importmap，否则会出现版本割裂。在蓝绿部署或灰度发布场景下，这种全局状态的一致性维护成本极高。

性能对比：实测数据说话

我们假设一个标准场景：基座应用（Shell）加载三个微应用（A、B、C），共享 React 和 ReactDOM。

关键发现：

• 在理想网络环境下（宽带、现代浏览器），Native Federation 的 TTI（Time to Interactive）确实快 100-200ms，主要赢在减少了 runtime 执行时间。
• 但在弱网或高延迟场景，Module Federation 的预加载和智能缓存策略反而表现更稳定。
• 当微应用数量超过 5 个时，Native Federation 的 importmap 体积会膨胀到 10KB+，解析开销开始显现。

2025 年现实 checklist：什么条件下可以迁移？

与其说"取代"，不如建立明确的迁移评估标准。如果你在 2025 年考虑从 Module Federation 迁移到 Native 方案，建议先确认以下硬性条件是否满足：

✅ 浏览器基线统一

• 用户群体 95% 以上使用支持 Import Maps 的现代浏览器
• 或接受 es-module-shims 在低端设备上的性能损耗

✅ 基础设施就绪

• 拥有完善的 ESM CDN（如 jspm、esm.sh 或自建）且支持 SRI（Subresource Integrity）
• 构建工具链（Vite/Rollup）已支持生成符合 Import Maps 标准的产物
• 部署流水线支持原子性更新 importmap（避免版本不一致）

✅ 架构简化可能性

• 微应用间不存在复杂的运行时版本协商需求（如所有应用强制使用同一版本 React）
• 不需要 Module Federation 的 dynamic remotes（运行时动态注册新微应用）

✅ 安全策略适配

• CSP 策略可以调整为允许必要的 CORS 和模块加载
• 接受将核心依赖（React、Vue）托管在独立域名，承担相应的 SPOF（单点故障）风险

如果以上有任何一条无法满足，2025 年的 Module Federation 仍然是你最安全的选择。

结论：共存而非替代

技术演进从来不是非此即彼。2025 年更可能出现的场景是分层架构：

• 核心基座：继续使用 Module Federation 处理复杂的依赖共享和运行时编排
• 边缘微应用：对性能极度敏感且依赖简单的场景，采用 Native Federation 或原生 ESM 加载
• 混合模式：通过 Module Federation 加载 Native Federation 的适配层，实现渐进式迁移

Import Maps 和 Native Federation 确实是微前端架构的重要补充，但它们解决的是"模块解析"这一层的问题，而 Module Federation 解决的是"应用编排"和"运行时治理"的问题。

对于一线开发者，2025 年的务实策略是： 在新的小型微应用或内部工具中尝试 Native Federation，积累 Import Maps 的运维经验；但对于核心业务系统，保持 Module Federation 的稳定性，等待标准真正成熟（可能是 2026 或更晚）。

毕竟，架构选型的第一原则是控制风险，而不是追逐最新提案。