微前端真是虚虚实实，自从17年参加工作，微前端的概念就风起云涌。最早的时候，个人在一个项目中因为实际情况的需要，实现了一个简易的微前端，当时的实现原理和qiankun类似，但是没有实现 qiankun 的沙箱，因为系统间的隔离并没有如此彻底。当时的场景主要解决的是：
- 工程体积
- 多团队维护的问题
再到后来，对于微前端的概念的就是伴随qiankun的诞生，似乎是一个在性能和实际原理之间做了一个很好的权衡。原理和接入难度都不高。似乎找到了一种银弹，但毕竟是沙箱运行，多应用之间的隔离，尤其是样式的隔离总是不彻底。再加上加载性能等各方面原因，在大厂也算是不温不火，有场景但不多。
到现在比较流行的大概再次伴随 Module Federation 的诞生，基于模块的隔离和共享，也算是一种微前端的思路。但是这个方式对于模块的管理、构建、组织带来非常大的难度。可以想象的是除了一些大厂有人有钱可以走向此方案，对于一般的小型公司，基本是不太可能。
为什么到现在我还在纠结微前端？
最近有一个实际的场景，对于一个企业来说，面临多方的业务和系统，同时系统本身必须要有一个统一入口，但这个系统看起来又不需要整体统一，系统之间的独立性也非常高。就是将各类系统聚合到一个大的统一入口中，及万物皆可接入。
需求似乎挺合理，但实际操作起来难度不小，例如系统本身可能还有不可改造的系统。
调研了市场上的微前端的方案，并没有特别的银弹的做法，受制于浏览器的能力本身，原理其实也归一：解析页面、执行JS、隔离CSS。基于此种原理目前比较流行的是qinakun以及腾讯的wujie。
原理类似，但实现思路wujie看起来更加独立，基于webcomponent、iframe能够更好的做到隔离。qiankun的又是则是和主系统的融合性更好，整体渲染的都是基于当前窗口，好处是可以共享完整的接管路由、token等等。
既然没有银弹，那能否暂且做一个缝合怪，将各个模式融合进来，哪个适合就接入哪个呢？
尝试缝合qiankun和wujie
基于当前的qiankun和wujie的模式，在一个主应用对于两个模式的融合，必须以组件的形式进行耦合，则主应用需要一个转发路由。
可以直接在应用启动的时候，将乾坤先进行注入
对于qiankun来说，到这基本算结束了，无非是在qiankun模块触发的组件内，完成应用的启动即可。
对于wujie问题多一点了，首先关于js加载，因为wujie的加载js是在一个隔离的iframe中，这里就涉及到如何将两边的pathname和hash进行同步的问题。wujie选择的是在主应用增加一个特殊参数，将参数与内部的iframe同步，基于此种场景，wujie只能选择使用单例模式和重建模式。
这里的关键问题是主应用的向下传递只能在初始化的时候单次传递。这就给后续的路由切换带来了不小的难度。例如当前是同一个子应用，路由信息的同步只能从底到上。没有实现双向绑定的能力。wujie提供的思路是：
这样带来的问题是子应用必须进行改造，路由的切换得接收两套模式。另外一种实现思路则是在主应用切换的时候，将wujie进行销毁，并内部进行重载。
最终在页面跳转的时候则需要进行特殊处理
const wujie_goPath = async (_path: string) => {
if (router.currentRoute.value.path.startsWith('/wujie')) {
bus.$emit('routeChange', _path)
} else {
await router.push({
path: '/wujie/',
query: {
vue_alone: `/wujie/#${_path}`,
},
})
// 重新加载同步主路由,使用重新刷新页面的方式，进行参数内传。
location.replace(window.location.pathname + window.location.search)
}
};看起来是相当丑陋，尤其对于路径的处理，需要进行replace进行整体应用的重载，或者在wujie组件跳出的时候，将wujie销毁，核心还是wujie只会在初始化的时候获取主应用上的参数。
这里只是冰山一角，实际操作中出了你会看到qiankun和wujie 给你整理的一些坑之外，你可能还会碰到各类奇艺问题，因为项目本身就会有一些各类诡异。
项目可能碰到的问题
wujie列出的一些问题：https://wujie-micro.github.io/doc/question/
qiankun列出的一些问题：https://qiankun.umijs.org/zh/faq
Q1. 如果子应用的请求是基于相对路径
对于qiankun的接入：
option1：子应用进行改造，将接口请求改为全路径。
option2：子应用的域名需要针对具体接口进行转发
对于wujie的接入：
因为是借助iframe发起的请求，所以天然支持，只需要支持跨域即可。
Q2. 子应用存在三方构建资源，资源不在构建路径内，即此时的资源请求（JS、Css等）是相对的路径。
这个场景下__webpack_public_path__并没有效果。资源的请求本身就需要依赖额外的相对路径请求。
对于qiankun的接入：
这个时候使用qiankun必然无法加载资源，因为qiankun的资源路径全靠全路径的拼接，相对路径必然失效，此时，只能选择要么将资源进行打包，要么将资源拷贝到主应用的文件夹中。
对于wujie的接入：
这个情况天然支持。
同样的问题对于应用中涉及到相对路径的资源均类似！从这一点看，wujie确实具有天然优势。
最后
从独立性上看wujie或者iframe本身具备有更优雅的独立性，对于接入成本也相对更低。qinakun则可能是在性能及一致性上显得更好。
所以目前看来比较好的选型大概是：
