微前端应该是最后的选择
微前端这个概念在前端开发这个方向里面已经不是新鲜事情了，前几年沸沸扬扬，基本每个前端开发都会将「了解微前端开发」写到自己的简历上，各种微前端方案也是层出不穷：
最初的 single-spa，到基于 single-spa 实现的 qiankun，将 js 沙盒和 css 隔离都做到了开箱即用；
再到基于 webComponent 实现的 micro-app，基于 webComponent + iframe 实现的 wujie；
另外还有直接使用 iframe 作为微前端方案（谁说 iframe 不是微前端呢，天生的上下文隔离就是它最大的优势），基于 webpack5 的 module federation 模块联邦，等等。
方案是真的一个比一个多，每一个后来者都在前人的肩膀上添砖加瓦，解决问题。
微前端的好处我们了解很多了，没有好处肯定也不会上这套新方案，那微前端也带来了一些额外问题：
- 性能变差。内网应用一般不太在意性能，但是也架不住微前端串行加载和多重 JavaScript 代码执行。由于加了这套框架，有些性能优化的手段也做不了，比如 SSR 不能做，子应用自身的请求 preload 也没什么成效（因为要等父应用加载完成子应用才能加载，不存在 preload 的时机了）。
- 问题复杂化。有一些问题其实并不复杂，比如父子应用的数据通讯、页面加载、埋点，很多问题在 SPA 上已经有最佳实践。但是一旦加上微前端，有了父子应用，就变得复杂了。比如父子应用的依赖复用问题、父子应用的通讯问题、沙箱相关的问题、样式隔离导致组件弹窗挂载位置不正确等问题。另外还有日常的研发成本和答疑成本。
- 技术耦合和门槛（这个词是照抄的，暂时我也没想到更好的词）。举个例子，前端大家都知道用 Vite 体验会比 webpack 更好，但是微前端早期的 UMD 引入方式限制了 Vite 的使用，再或者如果你用到了模块联邦你就必须用到 webpack，这些都是你引入了微前端方案后不得不舍弃的新技术。
回到最开始，我们为什么要使用微前端？
一般来说都是因为以下的几个点：
- 不同业务的技术栈不同，支持多框架多版本混用
- 融合 Pro Code 和 Low Code，即用在低代码平台内
- 统一导航头，下方内容不同业务分离拆分部署
上面的问题微前端都能解，但做技术人员经常会遇到的问题是：为了解决问题 A，引入了方案 B，然后方案 B 又引入了问题 C 和 D。聪明的同学会权衡问题 A 和 问题 C + D 的成本与收益，同时去看问题 A 是否有其他的解法。这个时候我们就面临着两个选择，放弃解决问题 A，那问题 A 就是技术债；解决了问题 C + D，可能又有问题 E、F、G。这就是程序员的生命周期，高级程序员和初级程序员的价值在于能更早地看到问题 C 和 D，从而更早地做出决策，减低试错成本。
回到上面的那些问题，微前端能解，那微前端是唯一解吗？在平时工作中可以多问几个为什么。可能在支持多框架这个方向，它是唯一解，但有些 case 并不是，就比如统一导航头，我们也能通过 JavaScript + MPA 的方案来解，在以前没有微前端的时候很多业务网站跑得也没问题。不是所有情况都直接无脑上微前端。
微前端是一种解法，它应该是最后的选择，而不应该是默认配置。