环境
因为我们自己的项目自主编辑BI数据图表，为减少对BI数据图表的反复开发设计，因此我们要把自己新项目制成微应用以便于其他团队迅速用来应用。
实际上微前端这一概念一直广为人知，针对个人开发者而言，或是非常重要亲身触碰并开发设计一下有关的工程项目的。
每个微前端基本原理
- iframe
- Web Components
-
Custom elements ：一组 JavaScript API，容许您界定 custom elements 以及个人行为，然后再在你的操作界面中依照需要使用他们。
-
Shadow DOM ：一组 JavaScript API，用以将封装形式的“身影”DOM 树额外到原素（与主文档 DOM 分离展现）并控制其关联作用。用这种方式，大家可以维持元素作用私，那样他们就能够被脚本化和式样化，而不必担心与文档的其余部分发生争执。
-
HTML templates：<template>和 <slot> 元素使大家可以撰写没有在展现页面上标注的标识模版。随后他们可作为自定原素构造的前提被数次器重。
-
single-spa(qiankun)的路由器挟持计划方案
-
Webpack5 Module Federation
-
每一个搭建都当做一个器皿，还可以将别的搭建做为器皿。用这种方式，每一个搭建都可以通过从相匹配容器里载入控制模块来浏览别的器皿暴露出来的控制模块。
-
分享控制模块就是指既可以重新写过的也可做为向嵌入器皿给予重新写过的控制模块。他们一般偏向每一个搭建里的同样控制模块，比如同样的库。
通过
Custom elements ：一组 JavaScript API，容许您界定 custom elements 以及个人行为，然后再在你的操作界面中依照需要使用他们。
Shadow DOM ：一组 JavaScript API，用以将封装形式的“身影”DOM 树额外到原素（与主文档 DOM 分离展现）并控制其关联作用。用这种方式，大家可以维持元素作用私，那样他们就能够被脚本化和式样化，而不必担心与文档的其余部分发生争执。
HTML templates：<template>和 <slot> 元素使大家可以撰写没有在展现页面上标注的标识模版。随后他们可作为自定原素构造的前提被数次器重。
single-spa(qiankun)的路由器挟持计划方案
Webpack5 Module Federation
每一个搭建都当做一个器皿，还可以将别的搭建做为器皿。用这种方式，每一个搭建都可以通过从相匹配容器里载入控制模块来浏览别的器皿暴露出来的控制模块。
分享控制模块就是指既可以重新写过的也可做为向嵌入器皿给予重新写过的控制模块。他们一般偏向每一个搭建里的同样控制模块，比如同样的库。
大家项目在更新改造微前端的过程当中，用了许多计划方案，来分享一下项目改造的一个过程。
因为我们项目做为微应用曝露出来的，他人连接大家新项目无法对本身新项目做过大更新改造，因此我们工程项目的微前端更新改造优先选择是尽量避免的对主运用的侵略性(因此下列还会说每个微前端的缺陷，目的在于兼容个人需求，自然所提到的每个架构全是很优秀的)
Webpack5 Module Federation(emp)
因为当时我们自己的项目应用vue-cli@4脚手架搭建的，必须升级成webpack5才可以Module Federation，所以才可以借此机会更新到webapck5
如果你想要Module Federation完成微前端，主要缺点一定要主运用也需要升成webpack5才能进行，所以这一更新更重要的是为了能新项目加快建设速率，根本无法事实上用以营销推广微前端过程。
qiankun
一说到微前端，坚信大部分人都是首先会想起qiankun，终究它上线的时长较早，因此我一开始都是试着应用qiankun。
- <img :src="`${$publicPath}/imgs/logo2.png`" class="logo-icon" />
<img :src="require('public/imgs/logo2.png')" class="logo-icon" />
- 根据内联方法手动式引进Keypress监视键盘事件，应用window.keypress也会导致微应用载入出错
<script src="./js/keypress-2.1.5.min.js"></script>
this.keyListener = window.keypress
重新编辑：
const keypress = await import("@/assets/js/keypress-2.1.5.min.js");
this.keyListener = new keypress.Listener();
因为qiankun都是基于路由器url开展挟持的，因此在开展复位微应用时，非常麻烦的一点是必须对路由器配对逻辑性进行调整，如下所示官方网demo：
import { registerMicroApps, start } from 'qiankun';
registerMicroApps([
{
name: 'react app', // app name registered
entry: '//localhost:7100',
container: '#yourContainer',
activeRule: '/yourActiveRule',
},
{
name: 'vue app',
entry: { scripts: ['//localhost:7100/main.js'] },
container: '#yourContainer2',
activeRule: '/yourActiveRule2',
},
]);
start();
由于这种路由器配对逻辑存有，造成了我们应该对主运用开展大幅编码改动，因此我们临时先选择放弃qiankun这个方案。
Vue.component git subtree webpack装包
以前在2022年头情况下，micro-app和wujie都还没发布，不过我们有相关市场需求的新项目，基本上都是应用vue2架构，因此这个方案便被选用的是。
这个方案的实现工作原理是，在微应用中完成部件注册注册，并通过webpack装包新项目，再通过git subtree提交搭建包，主运用根据git subtree升级部件包，然后再进行重新发版。
这个方案的主要缺点，必须要在vue2新项目中间，而且每一次微应用改动蜀主运用都需要重新走一遍发版步骤，因此在micro-app和wujie出来以后，大家很快就展开了拆换。
micro-app
虽说我们使用Vue.component git subtree webpack装包计划方案可以解决那时候的需要，但随着时间推移，己经有vue3和React项目需要连接我们自己的新项目做为他的微应用。恰好京东官方上线了micro-app时，就觉得能解决这些问题了，并且当年在改造为qiankun微前端时，就已经把一些工作做到位了，因此我马上就开启了根据micro-app的改造。
在连接的过程中，遇到了一个难题，大家主运用在载入微前端时，报这一不正确：
这一不正确最终找出来了，是因为人的index.html没有将body制成关闭标识(有意思的是这一bug一直没有被发现了):
<html>
<!-- 后边才发现是缺少了<body> -->
<body>
<script>
(function () {}(
……
))
</script>
</body>
</html>
wujie
实际上在腾讯wujie推出来之后，我们自己的微前端早已更新改造了好多次，基本上就可以做到无缝连接到wujie计划方案。正在看了官方网demo到编码后，wujie在兼容vite层面更为简单，所以最终也改成wujie计划方案了。
汇总
优先选择的解决方案是qiankun、micro-app、wujie，因为它载入微应用的形式也是通过http的形式，能够实现主运用和微应用间的耦合。
假如优先选择兼容性问题，能选micro-app，由于wujie是Web Components iframe的解决方案完成，每一个iframe的载入全是一个完整的html网页页面生命期，而且还要根据接口实现iframe和webcomponents的互连，因此wujie会很消耗特性(这个观点都还没准确的数据支持，只从基础理论角度而言之后专门去考察了一下，的确wujie相对而言特性差一点)
假如是优先选择兼容问题就选micro-app和wujie，由于qiankun更新改造成本费相对而言更高，而且不兼容vite 等 ESM 脚本运行。
本人极力推荐挑选wujie，由于wujie应用iframe去解决js防护和路由难题，尤其是在路由器这个问题上基本上无需再额外兼容工作中。