万象，2024年新鲜滚热辣的微前端方案

演示地址

仓库地址

前言

如何理解微前端？独立部署，无感加载，环境隔离？
微前端能解决什么问题？不影响老系统前提下开发新业务享受新技术带来的便利？拆分系统分散到各开发小组方便维护？
目前主流微前端框架 qiankun 是否满足上述所有诉求？

在尝试过用 vite 搭建 qiankun 项目后，我发现几个问题：

1、开发环境下主应用访问不到子应用，即使网上有很多方案，但始终还是做不到 js 沙箱和 css 样式绝对隔离
2、微应用切换时依然是加载所有资源，并不会比刷新页面加载的资源少

既然加载的资源不会比刷新页面少，那么我们可不可以直接刷新页面呢？只要首屏资源足够轻量，响应速度足够快，同样可以达到无感切换。我参与过不少用 webpack 搭建的 qiankun 项目，几乎所有项目都是主应用加载菜单，子应用业务内容在右侧主体区域显示的模式。那么换个思路，所以业务应用都优先加载菜单，通过本地缓存记录菜单数据、状态甚至滚动位置，是否就可以达到无感刷新切换应用的效果？而用这种传统的刷新页面方式根本不用考虑 js 、css 被其它应用污染的问题。

对比

方案	乾坤	万象
运行方式	拦截子应用代码，经过转换再挂载到主应用	没有主子应用之分，只有简单的加载公共菜单
沙箱隔离	支持 js、css 沙隔离，但 js 通过 with 限制作用域，css 通过自动添加前缀，转换过程中有性能损耗	天然隔离，无须各种转换，切换应用直接刷新页面，不存在性能损耗
子应用	支持	不支持
更新部署	只有主应用更新时，无须更新子应用	公共菜单更新时，需要更新所有应用
复杂度	主子应用使用相同技术栈比较容易上手，使用不同技术栈样式隔离比较头疼	为了保障菜单加载速度，达到无感刷新效果，使用纯原生技术开发，对维护菜单的开发者技术要求较高
掌控度	遇到bug需要向社区反馈，等待解决方案，自行修改源码难度较高	整体就一个菜单组件的代码量，完全可以自行修改源码
成熟度	蚂蚁内部服务了超过 2000+ 线上应用	新鲜出炉，还没遇到什么坑，理论上应该没什么坑

目录结构

bash 复制代码

--/
  |-- common/  # 公共组件模块
    |-- wanxiang/
  |-- app1/    # 应用1，独立仓库
    |-- package.json
  |-- app2/    # 应用2，独立仓库
    |-- package.json
  |-- package.json
  |-- .gitignore  # 忽略掉 app1 和 app2

如上图目录结构，有3个git仓库，一个公共的，一个 app1，一个 app2

app1 和 app2 都可以通过配置依赖路径别名加载 common 的资源，朴素无华，没有花里胡哨的模块联邦。

多仓库模式能有效解决开发团队的权限问题，同时避免了 git 历史记录洪流。

开始

html 复制代码

<!-- index.html -->
<head></head>
<body>
  <div id="app"></div>
  <!-- 将 main.js 替换为 entry.js -->
  <script src="entry.js"></script>
</body>

js 复制代码

// enrty.js
import { start, setMenus } from 'common/wanxiang/index.js'

start(`#app`, () => {
  // 关键点，显示完主体菜单再加载业务代码
  import('./main.js')

  // 加载菜单数据
  fetch('/menu').then(res => res.json()).then(res => {
    setMenus(res.data)
  })
})

后语

万象不是框架也不是插件，是一种方案，一种管理大规模前端应用的方案，没有具体的标准，根据各自项目需求对公共菜单进行调整，因此每个项目都会有不同的表象，遂取名为"万象"。