合并路由与微前端框架的对比解析

一、概念

在实际项目中，前端团队常常面临一个问题：如何把多个 Vue 应用合并到一个整体系统中？

目前有两种常见方式：

合并路由表方案
- 子应用不再是独立系统，只提供自己的路由配置和页面组件。
- 主应用（Nuxt）统一收集所有子应用的路由并注册。
- 最终产物是一个完整的前端应用。
微前端框架方案（如 qiankun、single-spa、Module Federation）
- 子应用仍然是独立项目，可以单独运行、单独部署。
- 主应用只在运行时动态加载子应用，并负责挂载与路由转发。
- 各子应用甚至可以使用不同框架（Vue、React、Angular）。

二、原理

1. 合并路由表原理

子应用只需导出自己的路由配置，例如：

javascript 复制代码

// 子应用 A 的 routes.js
export default [
  {
    path: '/module-a',
    component: () => import('./views/Home.vue')
  }
]

主应用通过插件动态加载：

javascript 复制代码

// plugins/mergeRoutes.js
import moduleARoutes from '子应用A/routes'
export default defineNuxtPlugin(() => {
  const router = useRouter()
  moduleARoutes.forEach(route => router.addRoute(route))
})

打包后，所有页面都属于同一个 Nuxt 应用。

2. 微前端框架原理

主应用在运行时注册子应用：

php 复制代码

// qiankun 示例
registerMicroApps([
  { name: 'vueAppA', entry: 'http://localhost:3001', container: '#subapp', activeRule: '/app-a' }
])
start()

当访问 /app-a 时，qiankun 会从远程加载 vueAppA 的 HTML、JS、CSS，然后挂载到主应用。
子应用保持独立生命周期（mount/unmount），可以单独部署。

三、对比

维度	合并路由表	微前端框架
部署方式	主应用统一打包，子应用不能独立运行	子应用独立构建、独立部署
技术栈	必须统一（Vue）	可以混合（Vue + React + Angular）
性能	更高（没有运行时沙箱）	稍低（需要加载/沙箱）
发布策略	所有子应用一起发布	子应用可单独发布
SEO/SSR	完全支持 Nuxt SSR	大多子应用是 CSR，SSR 支持弱
适合场景	单团队，模块化整合	多团队协作，大型项目

四、实践

使用合并路由表的场景

一个团队同时维护多个 Vue 项目。
业务模块清晰，但最终只需要一个整体系统。
发布时可以接受"一次打包所有模块"。

使用微前端框架的场景

多个团队独立开发、独立发布。
各团队使用不同技术栈。
项目规模大，耦合度高，需要独立自治。

五、拓展

折中方案 ：

有时也会结合两者，例如：
- 核心业务模块通过"合并路由表"方式接入（性能更高）。
- 外部系统或独立团队的业务通过"微前端"方式挂载（保持独立性）。
未来趋势 ：

随着 Vite + Module Federation 的发展，远程组件共享逐渐成为轻量替代微前端的方式。

六、潜在问题

合并路由表

模块之间失去独立性，任何子模块的修改都需要整体打包。
不利于团队独立迭代。

微前端框架

SEO 与 SSR 难以兼顾。
样式/全局变量可能冲突，需要额外隔离（如 qiankun 沙箱）。
初始加载时性能开销较大。

总结

如果你的目标是单一产物、团队规模不大，直接用「合并路由表」方案即可，简单高效。
如果你的目标是保持子应用独立开发、独立部署、跨团队协作，那必须使用「微前端框架」。

两者不是对立关系，而是不同复杂度下的技术选择。

本文部分内容借助 AI 辅助生成，并由作者整理审核。