写在前面
上一篇Micro Frontends已经从概念定义及实现思路上探究了微前端是什么，而要彻底理解微前端的话，还需要想清楚这些问题：
为什么需要微前端？
微前端能解决什么问题？组件化解决不了吗？
微前端究竟带来了什么？多技术栈并存？统一的技术栈不好吗？
一.背景：为什么需要微前端？
从最初的 HTML 内联脚本，到 9102 年的几十万行 JavaScript 代码，前端已经变得越来越重：
几个 G 的前端代码库
数百号前端开发人员
几 MB 的 Bundle Size
也越来越复杂：
层出不穷的框架、类库
各式各样的工程化体系
别具特色的跨端实践
因而需要一种分解复杂度、提升协作效率、支持灵活扩展的架构模式，于是，微前端登上了舞台
二.应用场景：微前端能解决什么问题？
微前端的理念类似于微服务，将庞大的整体拆成可控的小块，并明确它们之间的依赖关系。
通过拆分自治、支持多技术栈并存的方式，解决前端应用所面临的种种问题：
业务模块间日益加剧的耦合如何治理？
开发团队如何拆分、解耦，才能达到并行开发的目的？
新框架、新方案如何适应现有的工程环境（构建工具等）？
旧的框架类库如何平稳升级？
按业务功能将一整块前端应用分解成一系列更小、更内聚的微前端应用，同时通过明确的交互协议来管理这些应用间的依赖关系，实现不同业务模块的解耦。并将每个微前端应用交由独立团队负责，各自独立开发独立部署，充分利用并行性
另一方面，在多技术栈并存能力的加持下，不仅能够低成本引入新的技术实践，还允许低风险地替换产品局部功能，意味着依赖项升级、架构更替、UI 改版等重大决策都能以循序渐进的方式平稳落地：
分解：将应用拆分成由一系列小型应用（子应用）组成的应用
替换：替换子应用
组合：确保替换过的能够和谐工作
通过微前端框架建立应用间的主从关系（1 个容器应用 + n 个子应用），接着进行局部替换，直至全部完成。然而，实践中通常需要在重构的同时保证新特性的持续迭代，所以实际流程可能是：
抽象：增加一层主从关系，比如通过前端路由来控制
扩展：新增子应用
组合：原应用直接作为一整个子应用，带着新特性（新增的子应用）上线
重构：（时间上能与扩展并进）分解、替换原应用
让重构等工作能够在相对较长的时间跨度下可控地渐进完成，而无需承担一刀切的资源需求与变更风险
组件化解决不了吗？
The problems they’re supposed to solve sound to me like they’re already solved by a good component model. So is this solving an organizational issue rather than technical one? Such as if two teams can’t agree on anything, even shared infra.
（摘自I don’t understand micro-frontends.）
诚然，组件化也能实现拆分自治，比如在 React 中可以通过React.lazy + Suspense的方式优雅地完成代码拆分
但这建立在组件模型统一（或者说技术栈一致）的前提下，而微前端的另一半优势在于能够打破单一技术栈的限制：
They are microservices in the browser. Meaning separately built and deployed frontend apps that can choose their own framework and libs. The purpose is organizational scaling and avoiding framework lock-in.
这是组件化、模块化等方案所无法满足的。同样的，git submodule、npm module 等拆分方案也都无法直接提供多技术栈并存的能力
三.意义：微前端究竟带来了什么？
工程价值
一半来自模块化带来的好处，诸如：
研发效率提升：多业务线并行开发，团队自治，独立迭代
交付成本降低：应用级功能复用
运维风险降低：变更范围缩小
另一半来自多技术栈并存能力的好处：
技术选择增多：不再与单一技术栈捆绑在一起，有助于新技术、新交互模式的实验性试错
可复用性增强：技术栈差异不再是功能复用的障碍，对于第三方模块尤为重要
重构风险降低：低风险局部替换，渐进地完成大规模重构
当然，允许多技术栈并存，并不意味着鼓励引入尽可能多的技术栈，因为更少的技术栈通常更有利于基础设施建设、资源复用与经验共享
商业价值
微前端视角下的 Web 应用是一系列独立功能的组合：
The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams.
因此，微前端应用能够像云计算背景下的云服务一样能够即取即用，实现应用模块级（第三方）功能的接入/融合，其商业价值在于：
细粒度、可组合的前端产品形态：前端产品/能力能够以更细粒度，更灵活的形态输出（像云服务一样按需自由组合）
微前端应用生态：规范化的微前端应用能够形成生态，进而产生类似于小程序的平台体系
