qiankun框架：

1、原理：通过在主应用引入每个子应用的入口文件(main.js)，进行解析，并指定渲染的容器(DOM)，其次每个子应用设置打包的文件为UMD，然后在main.js暴露(export)生命周期方法(bootstrap、mount，unmount)，然后再其mount进行渲染，也就是new Vue(...)，并在unmount执行destory。

2、应用加载：通过entry获取对应子应用资源并加载。

3、沙箱隔离：JS、CSS隔离。

4、内部通信：全局对象通信——订阅发布模式。

缺点：适配成本高（工程化、生命周期、静态资源路径、路由）、CSS隔离不完美。

emp解决方案：

基于 Webpack 5 的 Module Federation （模块联邦）实现，就是“去中心化”，在 emp 的方案中不需要中心化的基座，每一个微前端应用都可以通过远程调用的方式引入共享模块。

1、应用加载：无需基座，类似于npm的模块远程调用加载，需要部署基站应用管理维护这些模块

2、沙箱隔离：没有有效的 css 沙箱和 js 沙箱，需要靠用户自觉。

3、应用通信：调用远程的状态管理。

缺点：

1、对 webpack 强依赖，老旧项目不友好。

2、无有效沙箱。

3、社区活跃度不高。

qiankun框架：

在微前端架构中，我们应该按业务划分出对应的子应用，而不是通过功能模块划分子应用。这么做的原因有两个：

1. 在微前端架构中，子应用并不是一个模块，而是一个独立的应用，我们将子应用按业务划分可以拥有更好的可维护性和解耦性。
2. 子应用应该具备独立运行的能力，应用间频繁的通信会增加应用的复杂度和耦合度。

• 官方应用通信方式：Actions通信

主应用注册一个MicroAppStateActions实例actions，子应用在render渲染函数中将actions注入到自身实例中，通过注册观察者函数监听全局状态，有变更触发回调函数；也可通过setGlobalState设置全局状态。

• 基座架构

  

1. 路由/菜单管理

   中心化路由：子应用路由信息在主应用维护，限制了微应用的灵活性，无法独立运行？

   动态路由：微应用向主应用暴露自己的路由菜单数据，主应用在运行时，动态获取微应用的数据来生成自己的路由菜单。

2. 主题管理

   主题包主要包含 CSS 变量、组件库样式、语言包、静态资源、以及一些公用API。API直接挂载到全局window上，子应用可以直接访问。公共包可以放在common模块中，比如组件库、页面基类、axios等，主子应用共同使用。

3. 会话管理

   1、需要统一的权限体系

   2、子应用根据自身环境

   独立运行：判断登录状态是否在localstorage即可

   在微前端中运行：非跨域：从localstorage中获取用户信息，共享用户状态；跨域：主应用通过参数传递token给子应用实现免登陆

   3、基座启动后，根据用户信息拉取菜单、权限配置信息，渲染菜单导航框架；细粒度的权限控制，基座通过暴露API供子应用适配。

4. 多语言管理

5. 共享依赖

6. 应用通信

​ 1、全vue应用：使用vuex

​ 2、非全vue应用：使用qiankun的globalStateApi

• 运行容器