Module Federation 和微前端是什么关系？适合解决什么问题？

简化版

微前端是一种把大型前端应用拆成多个可独立开发、构建和发布子应用的架构思路；Module Federation 是 Webpack 5 提供的运行时代码共享机制，常被用来落地微前端，但它不是微前端的唯一方案。

详细版

微前端关注组织边界和交付边界：不同团队能独立维护页面、模块或业务域，并通过统一入口集成。Module Federation 关注技术机制：一个应用可以在运行时加载另一个构建产物暴露出的模块，并共享 React、Vue 等依赖。

它适合大型平台、多个业务团队并行交付、需要独立发布的场景。不适合为小项目强行拆分，因为它会带来版本治理、公共依赖、样式隔离、路由集成、监控和故障隔离成本。

回答时要区分 host、remote、exposes、remotes、shared，并补充运行时失败、依赖版本不一致和发布回滚策略。

完整版教学

一、先区分架构目标和技术工具

微前端解决的是“大前端单体”带来的协作和发布问题。一个后台系统如果有 20 个业务域、8 个团队、每周几十次需求发布，所有代码绑在一个仓库和一次发布里，会让沟通成本、构建时间和回滚风险越来越高。

Module Federation 是一种模块联邦机制，允许多个独立构建在运行时组合。它可以服务微前端，但微前端也可以用 iframe、Web Components、single-spa、路由级静态集成等方式实现。

记忆钩子：微前端是组织和交付架构，Module Federation 是运行时模块共享工具。

二、Module Federation 的核心角色

典型联邦应用里，壳应用叫 host，业务子应用叫 remote。remote 暴露模块，host 在运行时按配置加载这些模块。

Host 应用
  ├─ remotes: orderApp@https://cdn.example.com/order/remoteEntry.js
  └─ import('orderApp/OrderPage')

Remote 应用
  ├─ exposes: { './OrderPage': './src/OrderPage' }
  └─ shared: { react, react-dom }

remoteEntry.js 可以理解成远程模块清单和加载入口。host 并不在自己的构建产物里直接包含 remote 代码，而是在运行时根据远程入口加载需要的模块。

三、运行时加载和普通 npm 依赖有什么不同

普通 npm 依赖在构建时就进入依赖图，版本由 lockfile 锁定，发布时和主应用一起上线。Module Federation 的 remote 可以独立构建、独立部署，host 访问时再加载它。

维度	npm 包依赖	Module Federation remote
集成时机	构建时	运行时
发布方式	跟随主应用	可独立发布
版本控制	lockfile 固化	入口地址和共享依赖协商
故障形态	构建失败或包错误	远程加载失败、版本冲突

这种差异带来灵活性，也带来线上不确定性。host 构建成功不代表 remote 运行时一定可用，所以必须设计 loading、fallback、超时和监控。

四、shared 依赖为什么既重要又危险

如果每个 remote 都打包一份 React，页面可能加载多份框架运行时，体积变大，还可能因为上下文不一致导致 hook、状态或组件库异常。shared 用来声明共享依赖，减少重复和冲突。

但 shared 不是越多越好。共享依赖会形成隐式运行时契约：A 应用希望 React 18.2，B 应用希望 React 19，host 到底给谁？如果没有版本策略，就会出现开发环境正常、线上组合失败的情况。

shared: {
  react: { singleton: true, requiredVersion: '^18.2.0' },
  'react-dom': { singleton: true, requiredVersion: '^18.2.0' }
}

面试回答要强调：共享核心框架要谨慎，业务组件是否共享要看稳定性；跨团队共享越多，独立发布边界越容易被削弱。

五、微前端拆分要按业务边界而不是组件数量

拆分粒度过粗，仍然像单体；拆分过细，运行时集成成本会超过收益。常见做法是按业务域、路由域或团队边界拆分。

假设一个平台有订单、库存、会员、营销 4 个业务域，每个域每周发布 3 次。如果合在一个应用里，理论上每周可能有 12 次互相等待和回归；拆成 4 个 remote 后，订单域发布不必等待营销域，但公共布局和鉴权仍由 host 管理。

/app
  /orders      -> order remote
  /inventory   -> inventory remote
  /members     -> member remote
  /campaigns   -> campaign remote

拆分前要确认团队是否真的有独立交付诉求。只有 3 个人维护的小项目，为了“架构先进”引入联邦，通常会让调试、发布和依赖治理都变难。

六、工程落地必须补齐隔离和治理

微前端不是把页面加载出来就结束。样式可能互相污染，路由可能抢占，鉴权状态可能重复初始化，监控日志可能丢失上下文。

问题	常见治理方式
样式污染	CSS Modules、命名空间、Shadow DOM
路由冲突	host 统一分配 base path
权限重复	host 下发用户上下文和能力接口
远程失败	fallback 页面、超时、降级菜单
发布回滚	remote 版本化入口、灰度和回滚

如果线上 remote 加载失败率是 0.5%，每天 20 万 PV 就有约 1000 次失败体验。工程方案必须把这类运行时失败纳入监控，而不是只验证本地能跑。

七、什么时候不建议使用 Module Federation

如果项目主要痛点是首屏慢，先做包体分析、缓存和路由分包；如果痛点是组件复用，先考虑组件库或 npm workspace；如果痛点是多团队独立发布，再考虑微前端。

Module Federation 会让依赖关系从构建时一部分转移到运行时。运行时越灵活，观测、版本、容灾和安全策略就越重要。没有这些配套，系统会从“构建时复杂”变成“线上复杂”。

一个简单判断是：拆分后是否能减少跨团队等待，并且每个子应用能独立负责质量。如果答案是否定的，微前端多半不是当前优先级。

八、常见误区与追问

误区：Module Federation 就等于微前端。 它只是常见实现工具，微前端还包含组织边界、路由、隔离、发布和治理。
误区：remote 独立发布一定更安全。 独立发布减少等待，但增加运行时组合失败和版本不一致风险。
误区：shared 依赖越多越好。 共享越多，耦合越强；核心框架适合严格治理，业务依赖要谨慎。
追问：host 和 remote 分别是什么？ host 是消费远程模块的壳应用，remote 是暴露模块的独立构建。
追问：remote 加载失败怎么办？ 设置超时、fallback、错误上报、版本回滚和必要的本地降级能力。
追问：微前端如何做样式隔离？ 可用命名空间、CSS Modules、Shadow DOM 或约束组件库样式边界。

九、加强记忆

回答这题按“目标、角色、运行时、治理、取舍”串起来：微前端的目标是独立交付，Module Federation 的机制是 host 运行时加载 remote 暴露模块，并通过 shared 管理公共依赖。它适合大团队大平台，不适合小项目炫技；真正难点在版本、隔离、监控、降级和发布治理。

简化版

详细版