Module Federation 未来会往哪些方向演进？

Module Federation 的未来不会只停在 Webpack 插件上，它更像一种前端运行时组合协议：不同团队、不同构建工具、不同发布节奏的应用，可以在浏览器里按需拼装。趋势大致有三条：构建工具解耦、运行时治理增强、跨端与边缘场景扩展。

为什么会从 Webpack 走向多构建工具？

早期 Module Federation 和 Webpack 绑定很深，remoteEntry、share scope、runtime container 都来自 Webpack 的实现。现在 Vite、Rspack、Rsbuild、Rollup 生态都在补齐联邦能力，核心原因不是“换个打包器更时髦”，而是大型应用需要更快的本地启动、更低的构建成本，以及更容易接入已有工程。

js
// rspack.config.js
const { ModuleFederationPlugin } = require('@module-federation/enhanced/rspack')

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'shell',
      remotes: {
        order: 'order@https://cdn.example.com/order/remoteEntry.js'
      },
      shared: { react: { singleton: true }, 'react-dom': { singleton: true } }
    })
  ]
}

但这里有边界：多构建工具支持不等于随便混用。团队要先确认 remote 格式、ESM/CJS 输出、CSS 注入、公共依赖版本协商是否一致，否则本地能跑，线上可能在首屏、样式隔离或 chunk 加载上翻车。

运行时治理会变得更重要吗？

会。未来的重点会从“能不能加载远程模块”转向“能不能稳定、安全、可观测地加载”。大型团队会需要远程模块清单、灰度发布、版本锁定、回滚、SRI 校验、加载耗时监控和依赖冲突报警。尤其是把 remoteEntry 放到 CDN 后，缓存策略、文件不可变命名和清单更新就会影响事故半径。

json
{
  "remotes": {
    "order": {
      "entry": "https://cdn.example.com/order/1.8.3/remoteEntry.js",
      "version": "1.8.3",
      "integrity": "sha384-..."
    }
  }
}

这个方向的取舍很现实：治理越细，平台成本越高；治理太弱，微前端会变成“分布式脚本引用”。比较稳的做法是先管住入口清单和共享依赖，再逐步接入灰度、告警和回滚。

边缘计算和 SSR 会怎样影响 Module Federation？

SSR、Streaming、Edge Runtime 会让 Module Federation 从浏览器运行时扩展到服务端组合。比如 Shell 在服务端决定加载哪个 remote，先输出骨架，再把局部功能流式返回。好处是首屏更可控，也能按地区、租户、实验策略选择不同模块。

踩坑也明显：服务端不能假设所有 remote 都有 window、document；共享依赖要区分 server/client 版本；remote 不可用时必须有降级 UI。否则一次 remote 超时，就可能拖垮整个页面响应。

AI 和自动化会真正改变什么？

更实际的变化会发生在发布前后。平台可以根据路由访问量、错误率和用户路径，自动给高概率命中的 remote 做 preload，也可以在某个版本错误率升高时把 manifest 切回上一版。这里不要迷信“AI 自动调度”，因为预测错了会浪费带宽，甚至把低端设备的主线程压满。比较可落地的做法是先用规则驱动：高频路由预加载、低频模块懒加载、异常版本自动降级，再把历史数据用于优化阈值。

另外，组织层面的演进也不能忽略。Module Federation 越普及，越需要平台团队定义 remote 命名、版本保留周期、灰度比例和事故响应规则。否则技术上已经拆开，协作上仍然靠口头约定，最后会把跨团队发布变成新的瓶颈。

追问

Module Federation 会被 Vite 或 Rspack 取代吗？

不会，二者不是同一层东西。Vite、Rspack 是构建工具，Module Federation 解决的是运行时模块组合和依赖共享。未来更可能出现的是“Webpack 联邦实现”逐渐让位给“跨构建工具联邦协议”。真正要取舍的是团队愿不愿意为更快构建迁移工具链，同时承担插件成熟度和生态差异的风险。

远程模块市场靠谱吗？

内部模块市场有价值，公开市场要谨慎。企业内部可以把设计系统、结算组件、权限组件做成可搜索、可审计、可版本化的 remote，提高复用效率。边界在于业务组件通常依赖上下文、埋点、权限和主题，脱离原系统后复用成本并不低。踩坑最多的是只发布组件，不发布版本说明、依赖约束和降级策略。

共享依赖未来会怎么演进？

共享依赖会从简单的 singleton 配置，走向更明确的版本策略和运行时诊断。React 这类框架依赖通常必须单例，否则 hooks、context、路由状态都可能异常。工具层可以自动提示重复实例、版本漂移和 eager 配置不当，但不能替团队决定兼容边界。实际项目里要把共享依赖当成架构契约，而不是随手复制的配置。

安全治理需要做到什么程度？

至少要做到 remoteEntry 来源可信、版本可追踪、发布可回滚。对外部或跨团队 remote，建议加白名单、SRI、CSP 和发布审批，不要让任意 URL 进入运行时加载链路。取舍是安全校验会增加发布流程和调试成本，但它能避免供应链脚本被替换后全站中招。边界是前端校验不能替代后端权限，remote 里所有敏感接口仍必须走服务端鉴权。