Module Federation、qiankun 和 single-spa 应该怎么选？

Module Federation、qiankun 和 single-spa 都能做微前端，但它们解决的问题层级不一样。Module Federation 更像“模块级运行时共享和发布机制”，擅长跨应用复用组件、页面和依赖；qiankun 更像“应用级接入框架”，帮你加载、隔离和管理子应用；single-spa 更偏底层编排，负责不同应用的生命周期注册和路由调度。选型时不要先问谁更先进，而要先问团队需要共享模块，还是需要托管一堆完整子应用。

追问

三者最大的差异是什么？

Module Federation 的边界在构建系统和模块加载，它依赖 Webpack 5 或兼容实现，核心能力是 remote、exposes、shared。qiankun 的边界在浏览器运行时的应用沙箱，它关心子应用怎么挂载、卸载、隔离全局变量和样式。single-spa 更基础，提供生命周期协议，但很多加载、沙箱和样式治理要自己补。取舍是 MF 更适合同构建体系协作，qiankun 更适合旧系统整合，single-spa 适合愿意自己搭平台的团队。

如果公司里 React、Vue、Angular 都有，选哪个？

异构技术栈很多时，qiankun 或 single-spa 通常更自然，因为它们把子应用当完整应用接入，不要求模块层面的依赖共享。Module Federation 也能接异构应用，但跨框架共享组件的价值会下降，反而要处理运行时、样式和通信边界。边界是：如果只是把 Vue 页面挂到 React 主站，应用级微前端更省心；如果多个 React 团队要共享业务组件和设计系统，MF 更有优势。不要为了追求“更细粒度”而把异构老系统硬拆成 remote 模块。

性能上 Module Federation 一定更好吗？

不一定。MF 可以通过 shared 减少重复依赖，也可以按需加载模块，所以在同技术栈、治理良好的情况下性能很好。可如果 remote 拆得过碎、remoteEntry 缓存混乱、共享依赖版本不统一，它也会带来更多网络请求和运行时协商成本。qiankun 加载完整子应用看起来重，但对低频后台页面可能足够简单稳定。性能选型要看访问路径、缓存命中和发布频率，不要只看框架宣传。

样式隔离和全局变量谁处理得更好？

qiankun 在沙箱和样式隔离上提供了更直接的方案，适合接入历史子应用。Module Federation 默认不解决样式隔离，它只是把模块拿过来执行，CSS 命名冲突、全局状态污染仍要靠 CSS Modules、Shadow DOM、约定或设计系统治理。single-spa 也需要自己补齐这些能力。踩坑是用 MF 后误以为天然隔离，结果 remote 的 reset.css 改了 host 全站样式。

实际项目怎么组合使用？

它们不是绝对互斥的，大型平台里常见做法是 qiankun 托管历史完整子应用，新的同栈业务用 Module Federation 暴露页面或组件。这样能兼顾迁移成本和长期复用，但平台复杂度会上升，需要统一路由、权限、监控和发布规范。取舍是组合方案灵活，却要求架构团队持续维护边界文档。最怕的是没有治理地混用，最后每个子应用既有沙箱问题，又有 shared 版本问题。