Micro Frontend 是「过度设计」还是「必然选择」？
Micro Frontend（MFE）自 2018 年首次出现在 ThoughtWorks Technology Radar 以来，一直承受着赞誉与批评的两极。在 2022～2023 年「Monorepo + Turborepo」盛行的时期，MFE 一度沉寂，但自 2025 年起，随着 Module Federation 2.0 的稳定化、Rspack 投入生产实用，以及 AI Agent 拉大团队生产力差距——这三股顺风重新将其推上聚光灯。本文概览 2026 年 4 月当前的 MFE 技术栈，并介绍日本大型金融、SaaS、电商企业的三个渐进式迁移案例。
Module Federation 2.0：第二代的成熟
Module Federation 是 Webpack 5 于 2020 年引入的、在运行时从远程动态加载模块的机制。2.0 版本在 Rspack 团队（字节跳动）的贡献下，整备了同时支持 Webpack/Rspack 的新 API。改进点有三：第一，运行时插件系统使得「远程列表」「共享依赖版本」可在运行时动态修改，从而无需刷新即可实现 A/B 测试和按用户属性分发。第二，类型安全——2.0 版本将 `.d.ts` 文件打包到远程容器中，IDE 自动补全得以生效。第三，Chrome DevTools 扩展「Module Federation Inspector」支持实时可视化加载状态。
Rspack / Vite / Webpack：构建工具战线
Webpack 5 虽然地位趋于 legacy，但凭借生态系统的厚度，仍是现有大型项目的首选。Rspack 1.x 是基于 Rust 的 Webpack 兼容构建器，速度提升 5～10 倍，官方支持 Module Federation 2.0，已成为 2025 年以来的主流选择。Vite 6 通过 `@module-federation/vite` 插件提供支持，但与 HMR 及运行时解析的兼容性欠佳，在开发阶段视为实验性处理较为稳妥。Turbopack 截至 2026 年 4 月尚未实现 Module Federation 的官方支持，使用 Module Federation 的话需退回至 Webpack/Rspack 方案。
Single-SPA 与 iframe：另一条路
Single-SPA 是由应用 Shell 对多个 SPA 进行生命周期管理的方式，对于需要框架混用（React + Vue + Angular）的组织而言，至今仍是最佳选择。2025 年发布的 7.0 版本将启动开销降低了 40%。在实际操作中，最均衡的方案是 Module Federation + Single-SPA 的混合架构：由 Single-SPA 负责挂载控制，Module Federation 负责依赖共享。Zalando、IKEA 以及后文介绍的日本案例均采用了此构成。
边缘分发与缓存失效
MFE 最大的运维挑战是「远程版本的一致性」。2026 年的最佳实践是「不可变资产 + Manifest 间接层」：远程 JS chunk 采用基于内容哈希的文件名，以 `max-age=31536000, immutable` 长期缓存；只有入口 `mf-manifest.json` 使用短期缓存（`max-age=60`，`stale-while-revalidate=300`）分发。manifest 作为版本切换的间接层，更新 manifest 后在下一个 TTL 到期时，所有 Host 即可获取新版本。
无论是 Cloudflare、Fastly 还是 CloudFront，通过边缘 KV 统一管理 manifest 的运维方式已经确立。金丝雀发布则通过在 manifest 中设置 `traffic_split` 字段，并由 Module Federation 2.0 的运行时插件进行比例判断来实现。
案例一：某大型银行「账务系统前端」的拆分
某大型银行的网上银行将单体 React 应用（约 240 万行代码）拆分为 7 个按团队划分的 MFE。契机是「一个团队的变更阻塞其他六个团队的发布」「npm install 耗时 8 分钟」「构建耗时 22 分钟」等典型的肥大化问题。
采用的架构是 Webpack + Module Federation 2.0 + Single-SPA。Host 只包含账户概览、导航和认证的薄壳，动态加载「转账」「投资信托」「贷款」「信用卡」「纳税申报」「保险」「客服」7 个 MFE。
渐进式迁移历时 18 个月，首先拆出 Shell，再将现有单体作为一个 MFE 整体包裹（Strangler Facade），随后按功能单元逐步从单体中剥离 MFE。各团队可独立升级 React 版本，迁移完成时各 MFE 的 React 版本分布在 18 到 19.2 之间。
成果清晰：各团队平均构建时间从 22 分钟缩短至 3 分钟（缩减 86%），部署频率从每周 1 次提升至每天平均 12 次，故障影响范围从「全功能停止」缩小到「仅限相关 MFE」。在金融监管审计方面，每个 MFE 拥有独立的部署记录也成为额外优势。
案例二：某 SaaS 企业的 Rspack + Vite 共存
某 HR Tech SaaS 企业，其管理员门户（Rspack）与员工自助服务（Vite）采用了不同的构建工具。管理员门户体量庞大且需要兼容 IE11（老客户需求），员工门户以移动端为主并优先追求开发体验，因此需求差异导致了构建工具的分离。
MFE 集成的功能有四个：公共导航栏、通知中心、搜索、帮助对话框。这些功能分别来自独立仓库，以 Rspack 构建，两个门户均通过 Module Federation 2.0 加载。Vite 侧通过 `@module-federation/vite` 插件作为远程消费方集成。
经验教训是「共享依赖要尽量精简」。最初将 React、dayjs、Zustand 等大量依赖设置为 shared，但因 singleton 冲突导致了三次生产事故，最终只保留了 React、React-DOM、i18n Context 三个。Bundle 体积有所增加，但运维稳定性大幅提升。
案例三：某电商平台的边缘分发迁移
某大型电商的店铺构建器 SaaS，由于需要为每个租户提供自定义前端，与 MFE 具有高度亲和性。2025 年迁移至 Rspack + Module Federation 2.0，采用 Cloudflare Workers 根据租户 ID 动态生成 MFE manifest 的架构，实现了「仅向特定客户阶段性开放新功能」「按租户分发节日限定设计」且无需工程师部署介入。SEO 方面的陷阱通过 SSR 预解析 manifest 并静态嵌入结构化数据得以规避，有效索引率从 92% 提升至 98%。
是否应采用 MFE：决策检查清单
以下是判断是否采用的关键维度。符合 3 项以上时，MFE 值得认真考虑：团队数量 5 个以上且各自拥有独立发布周期；Monorepo 构建时间超过 10 分钟；需要不同框架或版本共存；需要按租户自定义分发；希望将故障影响范围限定在功能单元；需要按功能提供独立审计追踪。反之，若团队仅 1～2 人，构建时间在 3 分钟以内，且首要目标是首次加载的简洁性，则 MFE 属于过度设计。
结语：MFE 正进入「再发现」时代
借助 Module Federation 2.0 的成熟、Rspack 的发展、边缘分发的演进，以及 AI Agent 带来的团队自主性顺风，2026 年的 MFE 已从「部分先进组织的技术」跻身「条件匹配的组织的定石选择」。重要的是，不要将 MFE 作为「万能解」引入，而应作为针对组织痛点与业务需求的具体处方来使用。正如本文介绍的三个案例所示，在适当条件下，MFE 能在构建时间、发布频率、故障影响范围、自定义自由度等方面带来量级上的改善。在下一次架构讨论中以「MFE？那不是过时了吗」一句带过之前，有必要再次审视组织的现状。