# 关于微前端

这个概念怎么来的：

是从微服务概念扩展而来，摒弃大型单体方式，将前端整体分解为小而简单的模块，这些模块可以独立开发、测试和部署，同时任然聚合为一个产品出现在客户面前。

# 优势

微前端由于是多个子应用的聚合, 如果多个业务应用依赖同一个服务应用的功能模块，只需要更新服务应用，其它业务应用也就可以立马更新，从而缩短了更新流程和节约了更新成本

由于历史包袱，团队依旧存在使用陈旧而庞大的前端单体模式，被过时的技术栈或赶工完成的代码质量死死拖住后腿，严重到让人想推到重写（重写的风险其实也不小特别是没有单元测试的项目）。为了避免风险，我们一般倾向于逐步更新，减小上线风险使业务不受影响。

微前端能使我们更加自由的对产品各个部分做出独立决策（毕竟都拆分开了），让团队能做到持续的增加功能并且对原有的整体几乎不做修改，使我们的架构、依赖以及用户体验都能够增量升级。

如果主框架中有一个非兼容性的重要更新，每个微前端可以选择在合适的时候更新，而不是被迫中止当前的开发并立即更新。如果我们想要尝试新的技术，或者是新的交互模式，对整体的影响也会更小

每个单独的的微前端项目的源代码库会远远小于一个单体前端项目的源代码库。这些小的代码库将会更加易于开发. 避免了不相关组件之间无意造成的不当耦合(深有体会, 例如改了一个组件方法但这个方法另一个组件也在用从而影响到其它组件).通过增强应用程序的边界来减少这种意外的情况出现

这个和微服务类似(毕竟是从微服务概念扩展而来), 减少部署的范围, 从而降低了发布风险(不需要管其它子应用, 只需要关注当前更改).

多个团队可以根据业务内容纵向划分, 而不是跟技术栈划分

微前端不是一门具体的技术，而是整合了技术、策略和方法，可能会以脚手架、插件和规范约束这种形式展现出来，是一种宏观上的架构。目前有多种方案，都有利弊，需要根据自己当前的业务场景进行选择。
微前端并没有技术栈的约束。每一套设计方案都是基于实际需求出发的。如果是多团队统一使用了相同的技术栈，可能对微前端方案的跨技术栈使用并没有要求。相反如果团队使用了不同的技术栈，可能对方案的跨技术栈要求比较高
微前端不是银弹(重点!!!)