你可能不需要微前端

一切的起因要从 20 年的那个夜晚开始

取名 qiankun，意为统一。我们希望通过 qiankun 这种技术手段，让你能很方便的将一个巨石应用改造成一个基于微前端架构的系统，并且不再需要去关注各种过程中的技术细节，做到真正的开箱即用和生产可用。 对于 umi 用户我们也提供了配套的 qiankun 插件 @umijs/plugin-qiankun ，以便于 umi 应用能几乎零成本的接入 qiankun。

1. 主项目和子项目添加 @umijs/plugin-qiankun 依赖

2. 子项目 app.js 导出生命周期

3. 主项目添加注册子项目的注册信息

what？我的主应用样式怎么全崩掉了，不是说有样式隔离吗？

{
  loader: 'less-loader',
  options: {
    modifyVars: {
      '@ant-prefix': 'yourPrefix',
    },
    javascriptEnabled: true,
  },
}

wc！ router.push 怎么不起作用了

1. 作为子应用运行和独立运行有区别，他们的路由路径不一致，举个例子
• 独立运行的跳转路径 router.push('/list/item')
• 作为子应用的跳转路径 router.push('/sub-app/list/item')
问题不大，我可以判断当前子应用是否在主应用环境下，给他加个 base

2. 但是这引出来第二个问题，子应用没办法跳主应用的页面
在第一步我们给子应用添加了一个 base，跳主应用时 router.push('/user/info') 会自动转换成 router.push('/sub-app/user/info') 导致 404，思来想去都没想道什么好办法，最终在全局绑了一个事件总线，主子应用通过事件总线通信，让子应用调主应用的 router.push 去跳转，总算解决了路由跳转的问题，不过这又带出来了一个新问题，后面再说，目前看来页面至少能够正常工作，找个复杂的页面检查下

我去，这页面怎么这么卡

1. 接入 qiankun 框架后,卡顿现象凸显的问题

2. 使用 loadMicroApp 手动调用子应用后访问 indexDB 存在性能问题

3. 使用 loadMicroApp 手动加载多个应用时存在性能问题，求优化

4. 主应用加载一个 3D 的微应用时，3D 微应用的性能会降低到原来的五六分之一

5. 微应用嵌入框架后，导致内存占用增加，出现卡顿，独立运行没有问题

1. 代码外逃沙箱控制导致的全局冲突问题

2. 代码在沙箱内运行错误的问题（主要是 BOM，DOM 的 API）

3. 代码在沙箱中运行导致的性能问题

做技术哪有什么两全之策，都是取舍和平衡

1. 跨团队对一个大的项目做拆分，多团队并行开发的情况，这种情况不适合，想象一下，有个因为代码外逃沙箱控制导致的全局冲突问题，开发的时候没问题，放一起提测出问题了，你不得不和别的部门撕逼谁去改这个 bug
更严重的是，测试环境没测出问题，你这个版本的迭代无论是在测试环境还是本地都是好的，但是影响到了不在这个版本范围的其他功能，这个功能还是别的团队在做的，然后你们发上线了，线上出问题了，惊不惊喜，意不意外，你猜会不会有人砍你

2. 过于老旧的项目，因为很难做到完全零成本的迁移，适配的过程需要修改很多问题，如果这个老项目属于典型的代码 💩 山，存在大量不规范编码问题，你可能会改的很痛苦，甚至完全改不动

3. 技术栈迥异的项目，比如主项目是 React，子项目是 Vue，他们使用不同的 UI 库，一方面完全没办法做公共依赖抽取，另一方面也很更容易出现很明显的样式污染

1. 拆解后的项目由一个团队维护而不是跨团队协作，因为项目迭代的生命周期对团队成员透明，也更可控，不会出现跨团队撕 X 的问题（对于稳定性要求不高的项目可以无视这条）

2. 主项目和子项目使用相同技术栈，使用相同的技术栈可以实现主项目抽离公共依赖和全局样式，一方面是可以提升加载速度，减少内存消耗，更重要的是，这是唯一可以尽可能减少全局样式污染的方式

3. 主项目这一层需要足够的薄，尽可能做到只包含登录，鉴权，布局这些基础逻辑，和业务相关的都放到子项目中，并且保证同一时间只有一个子项目，最大可能避免当代码外逃沙箱时的影响范围

4. 要拆解的项目最好是刚立项不久，或者项目还未创建，一方面新项目具备兼容微前端的工程能力，另一方面新项目使用微前端方案的成本最低，不需要改太多代码

故事的结尾

我落地了微前端方案，为个性化项目带来了代码拆分和业务模块复用的能力，极大提升了前端开发的效率，加强了项目的鲁棒性 ——— 我在 KPI 中如是说道

最后总结