2026 年微前端选型指南：wujie、qiankun、micro-app、Module Federation 全面对比

你有没有这种场景：旧系统只维护不改，新系统想用新技术栈独立开发，但用户需要一个统一的入口。

我最近就在做这个事——一个基于 Vue 3 + Element Plus + Avue + Vuex 的老管理后台，决定不再重构，新功能另起炉灶。经过完整的方案调研和 POC，这篇文章把四个主流方案的对比写清楚。

为什么需要微前端（以及你可能不需要）

先诚实说一句：微前端有成本。沙箱隔离、联调部署、数据通信——这些在单体应用里不需要操心的东西，微前端都要管。

什么时候真的需要：

条件	说明
多个独立系统需要统一入口	用户不用记多个 URL
旧系统不敢动	代码太老、太乱、没人敢重构
多团队独立部署	每个团队可以自由发版
渐进式技术栈迁移	Vue 2 → Vue 3，jQuery → React

什么时候不需要：

• 小团队（1-3 人）做新项目 → 单体应用更高效
• 旧系统还在频繁迭代 → 微前端会拖慢迭代速度
• 性能敏感型应用（编辑器、地图、大屏） → 沙箱有开销

我的场景属于”旧系统只维护 + 新系统独立开发 + 需要统一入口”，正好在微前端的适用区。

四个方案概览

             ┌─────────────┐
             │ 微前端方案   │
             └──────┬──────┘
                    │
    ┌───────────────┼───────────────┐
    │               │               │
┌───┴───┐     ┌────┴────┐     ┌───┴───┐
│ wujie │     │ qiankun │     │micro- │
│(腾讯) │     │ (阿里)   │     │ app   │
└───┬───┘     └────┬────┘     │(京东) │
    │               │          └───┬───┘
    │               │              │
    └───────────────┼──────────────┘
                    │
            ┌───────┴───────┐
            │ Module        │
            │ Federation    │
            │ (构建时方案)   │
            └───────────────┘

详细对比

wujie（无界）— 腾讯

核心原理：iframe 沙箱 + Web Components 容器

旧系统原样部署 → wujie 用 iframe 加载 → 通过 Web Components 挂载到主应用 DOM

接入方式：

<template>
  <WujieVue
    name="old-app"
    url="//old-app.example.com"
    :props="{ token }"
  />
</template>

关键特征：

维度	评价
旧系统改造成本	零—不改任何代码，原样部署
CSS 隔离	天然隔离（iframe 物理隔离）
JS 沙箱	天然隔离（iframe 自洽，无逃逸可能）
性能	好—iframe 创建有开销，但 wujie 做了保活和预加载
Vite 子应用支持	原生支持，不需要插件
数据通信	props + window.$wujie
学习成本	低—核心 API 就几个

适合：旧系统完全不动、异构技术栈、需要强隔离的场景。

注意：

• iframe 的弹窗/全屏跨域问题 wujie 做了处理，但非降级模式下仍有边界情况
• 英文文档几乎没有

---

qiankun（乾坤）— 阿里

核心原理：Proxy 沙箱 + HTML 入口加载

import { registerMicroApps, start } from 'qiankun'

registerMicroApps([
  {
    name: 'old-app',
    entry: '//localhost:8080',
    container: '#container',
    activeRule: '/old',
  }
])

start({ sandbox: { experimentalStyleIsolation: true } })

关键特征：

维度	评价
旧系统改造成本	有—必须改构建配置 + 导出生命周期函数
CSS 隔离	experimentalStyleIsolation 有坑，依赖命名约定
JS 沙箱	Proxy 沙箱，性能开销比 iframe 大
性能	中等—沙箱劫持开销 + 子应用每次切换重建
Vite 子应用支持	需要 vite-plugin-qiankun 插件
数据通信	initGlobalState
学习成本	中等—沙箱配置复杂，踩坑指南要熟读

曾经是微前端的事实标准，但 2023-2024 年后维护节奏明显放缓，核心团队已转向 wujie。 2026 年不推荐新项目使用。

适合：已在用 qiankun 的项目维持现有架构，不建议新接入。

---

micro-app（京东）

核心原理：Web Components <micro-app> 标签 + 资源劫持

<micro-app
  name="old-app"
  url="//old-app.example.com"
  baseroute="/old"
></micro-app>

关键特征：

维度	评价
旧系统改造成本	少，但需要少量配置
CSS 隔离	Scoped CSS，边界情况仍存在
JS 沙箱	Proxy 沙箱，与 qiankun 类似
使用体验	像用原生 HTML 标签一样，体验好
Vite 子应用支持	需要插件
学习成本	低

注意：

• 刷新后子应用路由状态有丢失问题
• 社区比 wujie 小，踩坑参考少

适合：想用 Web Components 方式接入、愿意接受少量改造。

---

Module Federation（构建时方案）

核心原理：Webpack 5 / Vite 编译时模块共享

// webpack 5
new ModuleFederationPlugin({
  name: 'main_app',
  remotes: {
    old_app: 'old_app@//localhost:8080/remoteEntry.js',
  },
})

关键特征：

维度	评价
旧系统改造成本	必须改构建配置
CSS 隔离	无—完全互通
JS 隔离	无—完全互通
跨技术栈	困难—适合同栈
开发体验	好—组件可以直接 import
Vite 支持	@module-federation/enhanced（2024 年才稳定）

不是沙箱方案，而是构建时模块共享。适合同技术栈、新建项目的场景。

适合：多个新项目共享组件库/工具库、同栈微前端。

---

横向对比表

维度	wujie	qiankun	micro-app	Module Federation
维护状态	✅ 活跃	⚠️ 变慢	✅ 活跃	✅ 标准能力
旧系统改造	零	必须改	少量	必须改
CSS 隔离	iframe 物理隔离	Scoped（有坑）	Scoped	无
JS 沙箱	iframe 物理隔离	Proxy 沙箱	Proxy 沙箱	无
Vite 子应用	原生支持	需插件	需插件	需插件
性能	好（保活+预加载）	中等	中等	好（编译时）
同栈体验	一般	一般	一般	最好
学习成本	低	中等	低	中等
中文文档	有	有	有	有
英文文档	几乎没有	少量	几乎没有	有

2026 年选型建议

场景一：旧系统零改造接入（最推荐 wujie）

旧系统：jQuery / Vue 2 / PHP / 任意老旧项目
旧系统策略：不改代码
新系统：Vue 3 / React

➡ wujie。唯一真正做到零侵入的方案，旧系统原样部署，新系统 <WujieVue> 加载。

场景二：同技术栈多应用共享组件

主应用 + 子应用，都是 Vue 3 + Vite
需要共享组件库、工具库、甚至 store

➡ Module Federation。编译时共享，体验最顺，类型安全。

场景三：已有 qiankun 的项目

已经在用 qiankun，跑得还行

➡ 继续保持 qiankun。迁移成本高于收益，等下次大改版再考虑切换。

场景四：高安全/金融场景

对 JS/CSS 隔离要求极高，不能有任何互相影响

➡ wujie。iframe 提供的是浏览器级别的物理隔离，这是 Proxy 沙箱做不到的。

场景五：小团队新项目

1-3 个人，从零开始

➡ 不建议用微前端。单体应用 + 合理的模块划分就够了。

我的选择：wujie

回到开头的场景——旧管理后台不动，新功能用 Vue 3 独立开发。

选了 wujie，理由很简单：

1. 旧系统一行代码都不用改—原样部署，风险为零
2. iframe 沙箱最省心—不需要操心 Proxy 劫持的边界情况
3. 新系统完全自由—Vue 3 + TypeScript + Pinia，想怎么搭都行
4. 配置极少—核心代码不超过 20 行

架构示意图：

┌──────────────────────────────────────────┐
│           新系统 Shell                     │
│  ┌────────────────────────────────┐       │
│  │  统一顶部导航栏                   │       │
│  ├──────────┬─────────────────────┤       │
│  │ 统一侧边    │  内容区               │       │
│  │ 栏菜单     │                      │       │
│  │          │  ┌─────────────────┐ │       │
│  │          │  │ wujie 加载旧系统  │ │       │
│  │          │  │ （原样部署）      │ │       │
│  │          │  └─────────────────┘ │       │
│  │          │  ┌─────────────────┐ │       │
│  │          │  │ 新系统原生页面    │ │       │
│  │          │  └─────────────────┘ │       │
│  └──────────┴─────────────────────┘       │
└──────────────────────────────────────────┘

总结

• 2026 年活着的微前端方案主要四个：wujie、qiankun、micro-app、Module Federation
• qiankun 不再推荐新项目使用，核心团队已转向 wujie
• wujie 是零侵入最优解，旧系统不改任何代码就能接入
• Module Federation 适合同技术栈的新建项目，但没有沙箱隔离
• 小团队新项目不建议上微前端，单体应用更高效
• 选方案先问自己：旧系统能改吗？团队几人？需要强隔离吗？

---

参考资源：

• wujie 官方文档
• micro-app 官方文档
• qiankun 官方文档
• Module Federation 官方文档