微前端容器选型：Qiankun 改造成本中等、Module Federation 共享依赖强，但“零侵入”的 Loader 方案

一篇 2026 年 3 月的微前端容器标准化改造文章，对四种方案给出了一个比较务实的评级。从改造难度、综合成本、风险三个维度看：Loader 方案（自研轻量级方案）难度低、成本低、风险低；Vite Federation 难度高、成本高、风险中；Webpack Module Federation 难度高、成本高、风险中；Qiankun 难度中、成本中、风险中。

这个评级的关键不是“谁最好”，而是改造难度和风险的分布为什么是这样。

Qiankun 基于 single-spa 封装，主应用在运行时动态加载子应用，子应用的生命周期由主应用编排，隔离靠 JS 沙箱和 CSS 沙箱。它的改造成本中等，因为子应用通常不需要修改构建配置，HTML Entry 的方式对存量应用比较友好；但沙箱不是万能的，严格沙箱需要显式启用，样式前缀需要注入，而且运行时加载本身有首屏延迟。它适合“多技术栈、需要强隔离、渐进式迁移旧应用”的场景。

Module Federation 的改造成本高，因为它是构建时的模块共享，要求统一的构建工具链（Webpack 或 Vite），并且需要重新设计依赖的暴露和消费方式。它的优势是依赖共享和模块级复用：多个应用可以共享一份 React 运行时、一份组件库、一份工具函数，减少重复加载。但“模块共享”不等于“应用隔离”，共享模块的状态被一个应用修改，另一个应用会受影响。它适合“统一技术栈、多个应用共享模块、追求依赖去重”的场景。

Loader 方案被这篇改造文章列为首选推荐，理由是“零侵入、低改造、高兼容，无需修改编译逻辑，适配存量业务”。它的核心行动项是：主容器接入 Loader 插件，子模块把本地的 Shared 依赖切换为 npm 共享包。这意味着它不改变子应用的构建方式，不引入运行时沙箱，也不要求统一构建工具链；共享依赖通过 npm 包的方式管理，而不是通过 Module Federation 的运行时共享。代价是它更接近“依赖共享”而不是“应用隔离”，适合的是“业务域通用容器标准化”这个具体场景，而不是“多团队独立部署”的全功能微前端。

一个可操作的选型顺序是：先问你要解决的是“依赖共享”还是“应用隔离”。依赖共享优先，Loader 或 Module Federation 的模型更匹配；应用隔离优先，Qiankun 的运行时沙箱和生命周期更匹配。再问技术栈是否统一。统一技术栈，Module Federation 的构建时共享更自然；多技术栈或存量系统，Qiankun 的 HTML Entry 和零构建修改更有优势。最后问团队愿意维护多少运行时复杂度。Qiankun 的沙箱和加载器需要运维，Module Federation 的共享配置和版本协商需要运维，Loader 的插件和共享包需要运维，没有一个是“配置一下就能长期不管”的方案。

微前端的选型不是“哪个框架更先进”，是“你的组织边界和技术栈形状，匹配哪种共享和隔离的粒度”。