微前端选型：qiankun 和 Module Federation 占据 65% 的市场，但它们解决的是不同粒度的问题

2026 年的一项前端社区调研显示，73% 的中大型团队已经采用微前端方案，其中 qiankun 和 Module Federation 占据市场份额的 65%。但这个数字容易误导选型，因为两者的技术定位并不在同一个粒度上。

qiankun 是基于 single-spa 的微前端框架，核心能力是应用生命周期管理、JS 沙箱和样式隔离，定位是“企业级微前端解决方案”，补全了 single-spa 缺失的沙箱隔离、样式隔离和静态资源加载。它的优势是开箱即用、强隔离、对存量应用友好，国内大多数团队把它作为默认选择。它解决的是应用级的隔离和编排：主应用加载子应用，子应用有独立的路由和生命周期，技术栈可以不同。

Module Federation 是 Webpack 5 的原生功能，解决的是模块级的共享：多个独立构建的应用可以在运行时共享模块，减少重复依赖，统一技术栈下的依赖去重。它不提供 qiankun 那样的应用级沙箱和生命周期编排，它假设多个应用在模块层面协作，而不是把一个应用嵌进另一个应用。

这个粒度差异决定了选型的判断顺序。先问你要解决的是“应用隔离”还是“依赖共享”。如果多个团队维护独立的应用、需要独立部署、技术栈可能不同、需要一个主应用来编排，qiankun 的模型是匹配的。如果多个应用共享同一套技术栈、希望复用组件库和工具函数、减少重复打包的 React 或工具库，Module Federation 的模块共享更直接。

再问你对“运行时开销”的容忍度。qiankun 的沙箱和动态加载有运行时开销，首屏可能比单体应用慢；Module Federation 的共享是构建时或运行时的模块解析，开销主要在版本协商和依赖管理上，不在沙箱上。两者的开销形状不同，取决于你的性能预算在哪里。

一个常见的错误是把 Module Federation 当 qiankun 用，试图用它做应用级嵌入，结果遇到路由协调、生命周期管理、样式隔离这些它本来不打算解决的问题；反过来，用 qiankun 做纯模块共享，会得到一个过重的运行时和一层不必要的沙箱。微前端的选型不是“哪个市场份额大”，是“你的组织边界和技术栈形状，匹配哪种隔离和共享的粒度”。