大型企业应用如何设计 Module Federation 架构？

大型企业应用使用 Module Federation，最怕把它当成“前端拆仓库工具”。仓库拆开只是结果，真正要设计的是业务域、运行时依赖、权限、发布节奏和故障隔离。一个 ERP、CRM 或运营后台可能有几十个团队参与，如果 Host 既管路由又管业务状态，还顺手持有所有 Remote 的细节，最后只是把单体应用换了一种方式继续维护。

更合理的架构是 Host 做薄，平台能力做稳，业务 Remote 做自治。Host 负责应用壳、认证、全局导航、布局容器、权限上下文和 Remote 注册；领域团队负责自己的路由片段、页面、接口适配和局部状态。公共 UI、埋点、国际化、权限 SDK 可以由平台团队维护，但要通过版本化包或共享依赖暴露，不要让每个 Remote 复制一份。企业级架构的关键不是“拆得多细”，而是拆完以后还能统一治理。

js
const remotes = {
  order: `order@${process.env.ORDER_REMOTE}/remoteEntry.js`,
  finance: `finance@${process.env.FINANCE_REMOTE}/remoteEntry.js`,
  crm: `crm@${process.env.CRM_REMOTE}/remoteEntry.js`
}

new ModuleFederationPlugin({
  name: 'enterprise_host',
  remotes,
  shared: {
    react: { singleton: true, requiredVersion: '^18.2.0' },
    'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
    '@company/auth': { singleton: true, requiredVersion: '^2.0.0' },
    '@company/design-system': { singleton: true, requiredVersion: '^5.0.0' }
  }
})

这里建议把 Remote 地址放进环境变量或配置中心，而不是写死在构建产物里。企业环境经常有灰度、专有化部署、私有云和多区域发布，同一套 Host 可能要加载不同版本的 Remote。配置中心还能做开关控制：某个 Remote 健康检查失败时，Host 可以隐藏入口或降级到旧版本。这个能力比多写几个 exposes 更接近企业架构的核心。

追问

企业级应用按页面拆还是按业务域拆？

优先按业务域拆，而不是按菜单或页面数量机械拆分。页面拆分短期看很直观，但订单详情、订单审批、订单售后往往共享同一套领域模型，拆到不同 Remote 后会产生重复接口适配和状态同步问题。按业务域拆能让团队对数据、路由和发布负责，边界更稳定。取舍是业务域 Remote 可能更大，需要做好懒加载和缓存；但它换来的是更清晰的责任边界。

Host 应该保存全局状态吗？

Host 可以保存认证态、租户、语言、主题、权限这类真正全局的上下文，但不应该保存订单列表筛选条件、财务单据草稿等业务状态。业务状态留在 Remote 内部，Host 只通过路由参数、事件或明确的 SDK 传递必要信息。否则 Host 会逐渐变成隐形单体，任何业务变更都要改主应用。踩坑点是全局 store 看起来方便，半年后会变成所有团队都不敢动的共享泥球。

大型企业里的权限和菜单怎么和 Remote 配合？

权限最好由统一权限服务计算，Host 根据权限决定入口是否展示，Remote 内部再做细粒度按钮和数据权限校验。不要只靠 Host 隐藏菜单，因为用户仍可能通过地址栏访问 Remote 路由。Remote 初始化时应拿到当前用户、租户和权限摘要，并在请求层继续带上服务端可验证的凭证。边界是前端权限只负责体验和防误操作，真正安全必须由后端接口兜底。

如何处理多版本共存和灰度发布？

企业应用很少能一次性全量升级，尤其是金融、供应链、内部运营系统。可以让配置中心按用户、租户或区域返回不同 remoteEntry 地址，并在监控里按版本聚合错误。取舍是灰度系统会增加排查复杂度，同一个 Bug 可能只在某个租户的 Remote 版本出现。为了降低成本，Remote 构建产物要带版本号、提交号和构建时间，错误上报也要携带这些信息。

设计系统和公共 SDK 升级有什么坑？

公共依赖升级是企业级 Module Federation 最常见的事故源。设计系统小版本改了样式变量、权限 SDK 改了初始化时机，都可能影响多个 Remote。建议先在兼容层保留旧 API，再逐步通知业务团队升级，最后才移除旧版本。不要强行让所有团队同一天升级 singleton 依赖，除非你已经准备好回滚和兼容验证。

大型企业架构里的 Module Federation，价值在于让组织边界和技术边界尽量一致。Host 保持稳定，Remote 保持自治，平台能力通过契约提供，系统才能在团队数量增加后仍然可维护。