摘要

本文针对业务域通用容器标准化改造需求，系统对比 Loader、Vite Module Federation、Webpack Module Federation、Qiankun 四种主流前端容器化方案，从改造成本、技术风险等核心维度剖析，输出可落地选型方案与实施建议，为企业级前端容器标准化建设提供决策依据。

前言

随着企业前端应用规模化发展，业务域通用容器的标准化、统一化、可复用性成为架构升级核心诉求。容器改造核心是实现主容器与子模块解耦、依赖共享、能力统一，同时最小化业务侵入、控制成本。本文梳理通用改造项，对比四种方案优劣，给出落地推荐。

一、必做通用改造项（所有方案共享）

以下基础改造为所有方案必做项，是业务正常运行的前提，需优先完成。

1.1 通用改造执行流程

1.2 App Context 核心能力适配

主容器与子模块需统一上下文依赖，确保互通，具体如下：

能力标识	功能说明
$gt	国际化翻译，保障多语言适配
request	统一 API 请求封装，规范调用
store	Vuex 全局状态共享，实现数据互通
router	Vue Router 路由跳转，保障导航统一
其他扩展	适配子模块自定义依赖，提升灵活性

1.3 ALB 网关适配

• 统一接口鉴权，实现登录态统一管理
• 配置本地代理，解决开发环境跨域
• 适配线上 ALB 反向代理，保障接口稳定

1.4 基础通用能力改造

• 支持 Excel、CSV 等文件下载，适配业务导出
• 规范 JS、CSS 资源路径，避免加载异常

1.5 CDN 静态资源适配

将字体、技术栈、UI 组件库、通用工具库等公共资源统一 CDN 加载，提升速度、降低服务器压力。

二、四大改造方案总览

从改造难度、综合成本、风险评估 3 个维度，对四种方案快速评级：

改造方案	改造难度	综合成本	风险评估
Loader 方案	低	低	低
Vite Federation	高	高	中
Webpack Module Federation	高	高	中
Qiankun	中	中	中

三、各方案详细技术解析

从核心行动项、方案评估、技术支撑 3 个维度，拆解各方案实操细节与优劣。

3.1 Loader 方案（✅首选推荐）

内部自研轻量级方案，零侵入、低改造、高兼容，无需修改编译逻辑，适配存量业务。

3.1.1 核心行动项

角色	改造内容
主容器	接入 Loader 插件，完成配置并启动
子模块	将本地 Shared/xx 依赖切换为 npm 共享包

3.1.2 方案评估

评估维度	评级	核心说明
改造难度	低	步骤清晰，无复杂配置
综合成本	低	改造量小，人力成本低
风险评估	低	零侵入，不改变原有业务与编译逻辑

3.1.3 技术支撑

核心插件：@portal/plugin-loader；共享依赖：@portal/shared-* 系列 npm 包。

3.2 Vite Federation 方案

基于 @originjs/vite-plugin-federation，适配纯 Vite 技术栈，兼容性待提升，不适配存量非 Vite 项目。

3.2.1 核心行动项

角色	改造内容
主容器	接入插件，配置 Shared 资源（Utils、Hooks 等）共享
子模块	接入插件，接收主容器 Shared 资源

3.2.2 方案评估

评估维度	评级	核心说明
改造难度	高	配置复杂，调试难度大
综合成本	高	主、子模块改造量均较大
风险评估	中	共享依赖兼容风险不可控

3.2.3 技术支撑

核心插件：@originjs/vite-plugin-federation（适配 Vite 技术栈）。

3.3 Webpack Module Federation 方案

Webpack 5 原生模块联邦方案，生态成熟，需将主、子模块构建工具迁移至 Webpack 5，改造门槛高。

3.3.1 核心行动项

角色	改造内容
主容器	迁移至 Webpack 5，配置 Shared 资源共享
子模块	迁移至 Webpack 5，接收主容器 Shared 资源

3.3.2 方案评估

评估维度	评级	核心说明
改造难度	高	构建工具迁移成本高，适配复杂
综合成本	高	改造量大，调试周期长
风险评估	中	迁移可能影响原有业务运行，共享依赖兼容风险不可控

3.3.3 技术支撑

• 构建工具：webpack@5+
• 核心能力：Webpack 原生 Module Federation

3.4 Qiankun 微前端方案

阿里开源成熟微前端框架，主打应用强隔离、JS 沙箱，支持多 JS 框架，适配跨团队独立开发场景，经线上验证，健壮性可靠。

3.4.1 核心行动项

角色	改造内容
主容器	接入 Qiankun，适配 Vue Router，配置 ALB 挂载子模块
子模块	接入框架，改造 Webpack，将本地 Shared/xx 依赖切换为 npm 共享包

3.4.2 方案评估

评估维度	评级	核心说明
改造难度	中	文档完善，核心难点为子模块 Webpack 改造
综合成本	中	子模块改造较复杂，整体成本可控
风险评估	中	子模块改造存在兼容风险，需充分调试

3.4.3 技术支撑

核心框架：Qiankun（官方文档完善，支持快速上手）。

四、方案核心维度对比矩阵

4.1 方案选型决策流程

4.2 多维度对比矩阵

对比维度	Loader	Vite Federation	Webpack MF	Qiankun
主容器改造成本	低	高	高	中
子模块改造成本	低	高	高	中
调试复杂度	低	高	中	中
生态成熟度	内部成熟	较新、兼容差	业界成熟	业界成熟

五、最终选型推荐

5.1 首选方案：Loader 方案

适配绝大多数企业存量业务，核心优势：改造成本、风险最低，支持渐进式改造，零侵入不影响现有业务，性价比最高。

5.2 备选方案适用场景

方案	最佳适用场景
Vite Federation	全新 Vite 项目，无存量业务负担
Webpack MF	全团队统一 Webpack 5，有充足改造周期
Qiankun	子应用需强隔离、跨团队独立开发

六、方案优劣势全景总结

方案	核心优势	核心劣势	推荐指数
Loader	成本低、风险低、零侵入，适配存量业务	内部方案，依赖团队支持	高
Vite Federation	Vite 原生优势，模块联邦能力	兼容差、调试难、改造量大	低
Webpack MF	生态成熟、稳定性强	改造量大，需迁移构建工具	低
Qiankun	社区活跃、隔离性强、支持多框架	子模块改造量大、配置复杂	中

七、结论

1. 通用改造优先：App Context、ALB、CDN 适配为必做项，奠定方案落地基础；
2. 存量业务首选 Loader：以最低成本、风险实现容器标准化，性价比最高；
3. 规避高风险改造：非特殊场景，不推荐 Vite Federation、Webpack MF 方案；
4. 按需选用 Qiankun：仅适配子应用强隔离、跨团队场景，通用改造无明显优势。