微前端解决了哪些业务问题？
为啥需要微前端我曾经给旺旺做外包，那时候做过的一个后台项目是自己第一个微前端项目。那时候很多微前端技术栈还不成熟，所以使用iframe方案。
管理后台型类型的项目，这类项目往往页面重复率高。有很多公司为了降本增效，有采用过低代码(在开发周期紧张的项目中，低代码可以有效的解决开发人力不足的问题)的方式进行过快速开发，很多低代码页面可能都存在开发和性能优化瓶颈，但是因为量大使用没办法短时间重构，于是在服务端不变的情况下，一个低代码需求就催生出来了。
微前端具有啥特性？
技术栈无关性：可以使用多类技术栈，Vue、React 或 Angular甚至JQ。
独立开发和部署：各个子应用可以独立进行开发、测试和部署，减少了相互之间的依赖和干扰，提高了开发效率和迭代速度。
低耦合：将大型前端应用拆分成多个相对独立的小应用，降低了整体的复杂度，使得每个子应用的功能更加聚焦和易于维护。
快速实现：一般服务端只需要进行极少的改动即可支持新项目。
团队自治：不同的团队可以负责各自的子应用，实现团队之间的自治和分工协作。
共享资源：在一定程度上可以共享一些通用的资源。(参考Monorepo技术方案，与我的另一篇博客 -> Monorepo-rush的入门操作)。
可以看出，微前端可以降低大型项目的开发、升级、维护以及团队协作的成本。也可以解决历史遗留的难以开发、升级和维护的大型应用，也是使用微前端的一个重要原因。
微前端有哪些方案？
在实际开发项目的过程中，如果项目本身采用 SPA 模式进行开发，则可以通过以下方案进行微前端改造：
基于框架（JavaScript SDK）的微前端：使用 single-spa、qiankun、wujie 等通用框架。
基于 iframe 的微前端：在主应用中使用 iframe 标签来加载不同的微应用；
其他解决方案，原理也都是在运行时动态加载不同的微应用，八仙过海，各显神通。
如果是MPA模式更简单，部署服务后，在主应用中通过服务端的路由来请求和渲染不同的微应用就好了。
实现微前端需要啥？
Iframe方案
为什么先讲Iframe，因为我第一个微前端项目就是Iframe，比较熟悉。而且iframe 最常用且超级稳定的微前端设计方案之一。
优点
兼容性，而众所周知，iframe是原生HTML标签，能加载其他web应用的内容，并且它能兼容所有的浏览器，因此，你可以用它来加载任何你想要加载的web应用。
硬隔离，不论是样式隔离、js 隔离这类问题统统都能被完美解决。
缺点：
硬隔离，过于强大的硬隔离导致应用间上下文无法被共享，随之带来开发体验、产品体验的问题（弹框类的功能无法应用到整个大应用中）。
速度，每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程，速度堪忧。
不是单页应用，会导致浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
搜索引擎无法读取其中的内容，自然也与SQO优化无缘
