前言

话说当下，前端职位在近十年的磨砺之下，已是百花齐放万家争鸣，前端也不再是以前那个单纯的切图仔；

要问为什么不单纯，无异于 前端工程化、前端 devops、前端跨端、前端工具化、前端 CI/CD、前端 BFF、微前端 这些技术的出现，然而这些日新月异的技术聚合，咱们可以称其为 前端基建；

其实无论您是想成为 高级前端工程师，还是一名 合格的 Leader，都离不开对 前端技术与业务的基础建设沉淀；

看完全文，我相信 您的收获会远不止于此 ~

一、什么是基建？

基建 这个词无论身处哪个行业，基本都会存在；只是在最近几年的软件计算机行业中尤为流行；

在建筑行业：一幢大厦所需的地基，脚手架，一块砖、一片瓦、一袋水泥、一扇窗等等咱都可以称之为基础建设的一部分；

在汽车行业：一辆汽车所需的车架子、发动机、车轱辘、方向盘、门窗等等咱也可称之为基础建设的一部分；

那么在互联网软件行业呢？

笔者的理解是：在软件行业，站在广义的角度上来讲基建包含了：业务基建、工程基建、前端基建、后端基建 等等；（此处仅笔者个人理解，如果意见不一样，以你的为准）

业务基建？

业务基建 是指公司某个业务团队层面所维护的 前端基建、后端基建、基本规范文档、产品规则、设计规范、研发流程、测试边界、上线标准以及业务中台 等等的建设；

业务基建 服务于整个业务团队

工程基建？

工程基建 指的是业务团队内所有工程师的的一些 编码规范、api规范、前后端协作、环境部署、微服务、微前端、性能、安全防御、统计监控、可视化 等等的建设；

工程基建 服务于整个工程团队；

前端基建？

前端基建 指的是业务团队内的前端工程师执行的一些基础建设，包括了 前端规范文档、前端脚手架、前端模板、前端组件库、前端工具库、前端BFF、前端CI/CD的构建部署、前端数据埋点 等等；

前端基建 仅服务于前端团队；

后端基建？

后端基建 指的是业务团队内的后端工程师执行的一些基础建设，包括了 后端规范文档、后端模板、安全、日志、微服务、RESTful API、中间件、数据库、分布式、权限控制、服务器性能并发 等等；

注意：后端基建 仅服务于后端团队；

关系图

看到这里，咱们已经明白了公司基建的一些基本分类和概括，下面我们也主要介绍下本文的主题前端基建；

二、为什么要做前端基建？

场景复现

场景一：

场景二：

场景三：

前端基建意义与作用

• 业务复用；
• 提升研发效率；
• 规范研发流程；
• 团队技术提升；
• 团队的技术影响力；
• 开源建设；

三、前端基建如何推动落地？

技术基建简要流程

要说 前端基建，最主要的难点莫过于如何去推动落地，其中不乏需要前端同学的付出，还需要领导的支持等等，下面我给大家罗列一下大致的步骤（因团队而异）

1. 要合适的同学（资源）
2. 挨个与前端同学商议，或者自己钦点某位同学等等；而且要有动力，切勿急于求成、半途而废，注重系统思维，也千万不要找不稳定的同学（切记切记切记）
3. 要解决的问题（问题）
4. 针对现有公司前端人员架构、技术架构以及业务架构做对应的方案，这个没有固定的套路，不同公司所面临的问题也不一致；
5. 要解决问题方案计划书（方案）
6. 到目前，咱们已经有人（前端同学），也有具体想要做的事了，那么接下来很重要的一步就是出解决方案找领导确认了；
7. 其实就类似你有一个很好 idea，写了一份特别详细的商业计划书（BP）去找投资人拉投资是一个道理；
8. 不过最后能不能打动你的投资人，这就取决于你的 BP 做的是否够吸引人了；
9. 要具体执行的步骤（执行）
10. 天底下没有一蹴而就的事，工作也是，所以对于一个现有的技术团队，咱们最好是从渐进式出发，在对现有业务不影响的前提下去做增量式的研发；

技术基建四大特性（切记）

• 技术的健全性
• 基建的稳定性
• 研发的效率性
• 业务的体验性

到这里，我相信大家对前端基建已有初步的了解，可能会有同学已经想跃跃欲试了，但是前端基建到底有些什么呢？咱们一起往下看。

四、前端基建都有什么？

前端基建 在每个公司甚者每个业务团队都会有差异，其中有 技术栈的差异，有编码的差异，有文档注释的差异 等等；

为了迎合主要的前端基建市场，结合我司以及大部分公司的基建所需，下面给大家介绍一些符合大众的常用基建部分（后续会持续更新）；

下面所有分类只会简单介绍，详细相关文章会在《前端搞基建》专栏后续发表（敬请期待…）；

1. 前端规范（Standard）

正所谓：前端不规范，后面看着办 ~

我相信规范两个词，是所有同学的噩梦，怕他不规范，又怕他太规范，这可真是难为死这个规范了；

假设招聘现有三个候选人，你会选择哪个呢？

• 一名 “摆烂” 的程序员，写的代码能运行就行；
• 一名 “合格” 的程序员，写的代码能运行且无 BUG；
• 一名 “优秀” 的程序员，写的代码能运行无 BUG 且可读性、可维护性、可复用性都高；

答案显而易见 ~

前端规范的意义：

• 降低开发的成本；
• 保证代码的一致性；
• 提升团队的整体效率；

前端规范有什么？

2.前端文档（Document）

其实在许许多多的小型公司，文档缺失是一项必不可少的问题；无论是 业务文档，还是 技术文档，还是 其它文档等等；

问题点：

• 有些公司招人进来上午安环境，下午直接开始撸需求代码；
• 有些公司的新人来公司一个月了竟然还不知道公司组织架构与业务划分；
• 有些公司老对新几乎无交集，全靠新人猜，一个需求做下来竟然不知道做的什么，只知道一直很忙；
• 有些公司在安排员工去开发另一个项目业务，竟然无从下手，不知所措；
• ……

所以一个合格的公司文档是必不可少的，无论是 新人自治，还是老带新，业务转岗 等等；

前端文档的意义：

• 对新人友好，快速上手；
• 快速融入团队；
• 快速了解业务；

前端文档有什么？

3. 前端项目模板管理（Templates）

前端项目模板 说直白点就是，公司前端所对应的项目模板，以便快速创建项目；

场景一：

前端项目模板主要意义：

• 快速创建项目，提升效率；
• 项目技术栈统一，方便管理；

前端项目模板有什么？

4. 前端脚手架（CLI）

前端脚手架 作为衡量一个成熟前端团队的标准，我相信很多前端er 都对他已经很了解了；

但是目前市面上对脚手架的应用我相信90%以上的团队仅限用于项目的快速创建，也就是使用现成的模板通过命令行快速搭建；

那么我们做这个脚手架是不是已经做到了 资源最大化 呢？

显然是没有的，如何去做我会在后续的文章中详解，大家敬请期待…

场景一：

前端脚手架的意义：

• 快速搭建项目；
• 技术栈统一；
• 规范代码风格；
• 提升研发效率；
• 自动化；

前端脚手架有什么？

5. 前端组件库（UI Design）

前端 UI 组件库：在开源社区有数不胜数的组件库，例如 Ant Design、Element UI、Vant UI 等等（实在太多啦），如果你觉得某个组件库很适合用在你的项目，那么你将少一半的开发时间，是不是摸鱼的时间又多了一半呢？

但是在一些中大型的公司，他们有他们的标准，不可能去使用一些现成的组件库；

而且现成的一些开源组件库中的样式与交互达不到公司设计师的要求，所以这时候 为了统一业务的设计规范与样式，咱们可以马不停蹄地赶紧向领导去提一提搞一个组件库试试看咯！

场景重现：

前端组件库的意义：

• 组件复用，提升研发效率；

前端组件库有什么？

6. 前端响应式设计 or 自适应设计

响应式设计（Responseive Design） 指的是一个网站同一页面在不同屏幕尺寸下有不同的布局；一套代码能在所有终端能够正常展示，并不是为每个终端做一个特定版本，响应式是为解决移动互联网浏览器而诞生的。

自适应设计（Adaptive web design） 需要开发多套界面，通过检测视口以及设备，来判断当前访问的设备是pc端与移动端，从而返回不同的页面。

前端响应式设计：

• 一套代码提升研发效率；
• 不同分辨率设备灵活性强；
• 快速适配多端；

前端自适应设计：

• 设计与体验较好；
• 性能相对好；

注意：

一个项目到底是用响应式设计，还是自适应设计，这个取决于项目的排版和设计的出入程度;

所以如果公司PC端和H5端的排版设计有较大的出入还是建议使用自适应设计；反之可以考虑响应式设计；

切入盲目选择；

7. 前端工具库（类 Hooks / Utils）

开源社区有数不胜数的 前端工具库，如 Day.js、axios、loadsh 等等，只是其中功能未必是你想要的；

而且许多 前端工具库边界考量范围大，这样就增加库的体积，明明我想要的只是一个简单的功能，可还是引入了整个库，这样就得不偿失；

可能有同学要说不是有 Tree Shaking 了吗，难道有了 按需引入 有了 Tree Shaking 我们就可以为所欲为了吗

一些中大型企业团队为了复用某些工具方法，提升研发效率，一般都会封装一个工具库，身为一个合格的基建搬砖工，前端工具库怎么能少得了呢？

前端工具库的意义：

• 工具方法复用，提升研发效率；
• 减少代码量；
• 团队技术提升；

前端工具库有什么？

8. 前端工具自动化（Tools）

可能会有同学疑惑，这个前端工具和上面的前端工具不是一样的吗？

• 前端工具自动化 主要针对的代码上层的格式、规范、测试方面的自动化工具；
• 前端工具库 主要针对的是代码层面的方法复用工具，所以其本质上有较为明显的区别；

场景重现：

前端工具自动化的意义：

• 代码质量与风格的统一；
• 自动化编码流程；
• 提升效率；

前端工具自动化有什么？

9. 接口数据聚合（BFF）

前端 BFF（Backends For Frontends） 即服务于前端的后端，也称聚合层或者中间层；

主要将后端复杂的微服务，聚合成对各种不同用户端（无线/Web/H5/第三方等）友好和统一的API；

场景重现：

前端 BFF 的意义：

• 聚合 API，释放后端；
• 解耦合各个业务；
• 后端微服务引入；
• 易维护和修改 API；
• 更好的安全性；
• 更好的前端错误处理；

前端 BFF 的简单架构：

10. 前端 SSR 推进

服务器端渲染（Server-Side Rendering） 是指由服务端完成页面的 HTML 结构拼接的页面处理技术，发送到浏览器，然后为其绑定状态与事件，成为完全可交互页面的过程。

简单理解就是html是由服务端写出，可以动态改变页面内容，即所谓的动态页面。早年的 php、asp 、jsp 这些 Server Page 都是 SSR 的。

由于公司主要是C端用户，而且 SEO 要求极高，所以在前后端分离的情况下，SSR 就必不可少了 ~

场景一：

前端 SSR 的目的：

• 前后端分离；
• 首屏加载速度快；
• 利于 SEO；

11. 前端自动化构建部署（CI/CD）

前端 CI/CD 一般是指持续集成、部署、发布的一个过程；

用白话文讲，就是你每次 git commit 代码后，都会自动的为你部署项目至 测试环境、预生产环境、生产环境，不用你每次手动的去打包后 cv 到多个服务器和环境；

前端 CI/CD 的意义：

• 提高开发人员生产力；
• 自动化发布；
• 提高代码质量；
• 更快地提供更新；

前端 CI/CD 有什么？

12. 全链路前端监控/数据埋点系统

在大部分 To C 的项目中，我相信产品和运营都需要 统计线上产品在用户中的行为和使用情况，因为这样可以更快的去了解用户群里的使用情况，从而升级和迭代产品，使其更加贴近用户。

场景一：

场景二：

前端监控/数据埋点的目的是：

• 实现精准的点对点营销；
• 可以做相关的分类统计；
• 为用户画像的构建提供数据支持；
• 指导产品研发以及优化用户体验；

前端监控/数据埋点有哪些数据？

• 行为数据：时间、地点、人物、交互、交互的内容；
• 质量数据：浏览器加载情况、错误异常等；
• 环境数据：浏览器相关的元数据以及地理、运营商等；
• 运营数据：PV、UV、转化率、留存率（很直观的数据）；

13. 前端可视化平台

前端可视化 字面意义理解就是用肉眼可见的就称呼为前端可视化；即所见即所得；

笔者这里的理解 前端可视化 包括了 数据可视化、图形可视化、VR 全景可视化、中后台视觉可视化 等等；

其中每一个都需要花费大量的人力与精力，如果你想全方面的从入门到精通，可以看看月影大佬的可视化教程。

目前公司在基于前端基建这块，所做的可视化主要是基于大家的工作流程以及工作效率所做的一个 工程可视化平台；

场景一：

场景二：

前端工程可视化平台的目的：

• 方便项目管理；
• 高效提升工作效率；
• 一键搞定CI/CD流；

前端工程可视化平台有什么？

14. 前端性能优化

性能优化这个词，我相信只要是程序员，多多少少都听过，而且都经历过；

如果你的项目是 ToB 项目，可能性能优化不会做到极致；

但是你的项目是 ToC 项目呢，那性能优化是不是就是一个你必须要考量的点呢？

场景重现：

好家伙，用户直接崩溃，这是什么破网站，这么 ；

前端性能优化的意义：

• 页面加载的更快；
• 更好的用户体验；
• 降低服务器负荷；
• 提升编码的能力；

前端性能优化都有什么？

15. 前端低代码平台搭建（建设中）

维基百科定义：低代码开发平台（LCDP） 本身也是一种软件，它为开发者提供了一个创建应用软件的开发环境；与传统编写代码的 IDE 不同，低代码开发平台提供更易用的可视化 IDE。

简单来讲，低代码（Low Code）就是一种可视化搭建系统，从字面意思来讲，一是可视化；二是少写代码。

无代码（No Code） 同样从字面上来理解，一是可视化，二是不写代码。

场景一：

前端低代码平台的意义：

• 降低开发成本；
• 所见即所得；
• 一站式研发；
• 技术收敛；
• 专业门槛低；
• 对新人友好，上手快；

注意：

低代码平台一般较针对于一些业务使用率较大且多是 ToB 的平台，所以判断当前系统是否需要使用低代码平台，建议在有大量业务的支撑前提下，否则得不偿失；

用新技术，更多的不是因为先进，而是适合。

16. 微前端（Micro App）

微前端（Micro-Frontends） 并没有定义框架或 API，它其实是一个类似 微服务架构 的概念；将 微服务 的概念扩展到了前端世界；

说微服务可能有些前端同学会感觉陌生，以咱们前端的角度一句话概括就是： 将您的大型前端应用拆分为多个小型前端应用，这样每个小型前端应用都有自己的仓库，可以专注于单一的某个功能；

需要强调的是，尽管我们将前端应用拆分为多个项目，但它们最终还是会被集成到一个单页前端应用程序中；因此，通过使用微前端架构，您不会在用户体验上有任何损失，只会有过之而无不及；

场景一：

为什么要用微前端：

• 技术上的灵活选择；
• 更快的且独立的部署；
• 团队代码的相互隔离；
• 并行开发和团队的自治；
• 项目的增量升级；

微前端的价值：

微前端带来的问题

细想一下：通过微前端常见的解决方案，其实我们是可以归纳一些微前端存在的问题，比如 样式冲突、消息通信、脚本互斥、公共依赖加载等问题；所以 微前端框架 就因为这些问题应运而生了。

1. 应用隔离

应用隔离主要分两种情况：

• 一种是 主应用与微应用之间的隔离；
• 一种是 微应用与微应用之间的隔离；

应用间所隔离的主要是 Javascript 的沙箱隔离和 CSS 的样式隔离；

CSS 样式隔离

由于在微前端场景下，不同技术栈的子应用会被集成到同一个运行时中，所以我们必须在框架层确保各个子主应用之间不会出现样式互相干扰的问题；

例如：一个团队的微应用的样式表为 h2 { color: black; }，而另一个团队的微应用则为 h2 { color: blue; }，而这两个选择器都附加在同一页面上，就会冲突；

为了避免这个问题，常见的解决方案有：

• 严格的命名约定，例如 BEM；
• CSS Module；
• 各种 CSS-in-JS 库；
• shadow DOM；

Javascript 沙箱隔离

每当微应用的 JavaScript 被加载并运行时，它的核心实际上是对全局对象 Window 的修改以及一些全局事件的改变，例如 jQuery 这个 js 运行后，会在 Window 上挂载一个 window.$ 对象，对于其他库 React，Vue 也不例外。

为此，需要在加载和卸载每个微应用的同时，尽可能消除这种冲突和影响，最普遍的做法是采用沙箱机制（SandBox）；

沙箱机制的主要特性如下图：

常见实现沙箱的方法：

• 沙箱快照；
• ES6 的 Proxy 代理；

2. 跨应用通信

微前端最常见的问题之一是如何让微应用之间能够相互通信。

一般而言，我们建议让微应用之间尽可能少地交流，因为这通常会重新引入我们最初试图避免的那种不适当的耦合代码。也就是说，通常我们只需要某种程度的跨应用通信即可。

常见的通信方式：

• 使用 自定义事件通信，是降低耦合的一种好方法；
• 可以考虑 React 或 Vue 应用中常见的 全局 state store 机制；
• 发布-订阅（pub/sub）模式的通信机制；
• 使用 地址栏作为通信机制；

正式因为这些问题的存在，所以就导致了一系列的微前端框架出现，下面主要给大家介绍下全世界范围内比较有名气的一些框架。

微前端框架

1. Single-spa

Single-spa 是最早的微前端框架，兼容多种前端技术栈；

概念：Single-spa 是一个将多个单页面应用聚合为一个整体应用的 JavaScript 微前端框架；

我们都知道 spa 应用 的理念是让独立的应用程序组成一个完整的页面，Single-spa 并不用依赖于单个框架和每个特性，而是你可以在不同的新框架随意使用；

简单来说就是一个聚合，使用这个库可以让你的应用可以 使用多个不同的技术栈（vue、react、angular等等)进行同步开发，最后使用一个公用的路由去实现完美的切换；

快速体验入口

优点：

• 敏捷性 - 独立开发、独立部署，微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新；
• 技术栈无关，主框架不限制接入应用的技术栈，微应用具备完全自主权；
• 增量升级，在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
• 更快交付客户价值，有助于持续集成、持续部署以及持续交付；
• 维护和 bugfix 非常简单，每个团队都熟悉所维护特定的区域；

缺点：

• 无通信机制
• 不支持 Javascript 沙箱
• 样式冲突
• 无法预加载

正是因为有了 Single-spa，才让大部分微前端框架得以出现，所以以下所讲的微前端框架几乎都拥有 Single-spa 的优点。

2. Qiankun

Qiankun 是一个基于 single-spa ，阿里系开源的微前端框架，旨在帮助大家能更简单、无痛的构建一个生产可用微前端架构系统。

设计理念：

• 由于主应用微应用都能做到技术栈无关，qiankun 对于用户而言只是一个类似 jQuery 的库，你需要调用几个 qiankun 的 API 即可完成应用的微前端改造。
• 同时由于 qiankun 的 HTML entry 及沙箱的设计，使得微应用的接入 像使用 iframe 一样简单。
• 微前端的核心目标是 将巨石应用 拆解成若干可以 自治的松耦合微应用，而 qiankun 的诸多设计均是秉持这一原则，如 HTML entry、沙箱、应用间通信等。这样才能确保微应用真正具备 独立开发、独立运行 的能力。

qiankun 的在线案例：

1. tech.antfin.com/partners
2. www.zstack.io/

优点：

• 基于 single-spa 封装，提供了更加开箱即用的 API。
• 技术栈无关，任意技术栈的应用均可 使用/接入，不论是 React/Vue/Angular/JQuery 还是其他等框架。
• HTML Entry 接入方式，让你接入微应用像使用 iframe 一样简单。
• 样式隔离，确保微应用之间样式互相不干扰。
• JS 沙箱，确保微应用之间 全局变量/事件 不冲突。
• ?? 资源预加载，在浏览器空闲时间预加载未打开的微应用资源，加速微应用打开速度。
• umi 插件，提供了 @umijs/plugin-qiankun 供 umi 应用一键切换成微前端架构系统。
• 社区较为活跃，维护者也较多，有问题会及时得到响应；

缺点：

• 可能对一些 jQuery 老项目支持性不是特别好；
• 安全和性能可能会有影响，具体取决于项目；
• 对 eval 的争议，eval函数的安全和性能是有一些争议的：MDN的eval介绍；

另外阿里系还有另外两款微前端框架：

Icestark，是一个面向大型系统的微前端解决方案； Alibaba Cloud Alfa，是在阿里云控制台体系中孵化的微前端方案，定位是面向企业级的微前端体系化解决方案；

这两款框架相较于 Qiankun 来讲社区活跃度以及 demo 较少，所以不太推荐使用该框架，大家了解即可。

3. Micro App

Micro App 是京东出的一款基于 Web Component 原生组件进行渲染的微前端框架，不同于目前流行的开源框架，它从组件化的思维实现微前端，旨在降低上手难度、提升工作效率。

它是目前市面上接入微前端成本最低的框架，并且提供了 JS沙箱、样式隔离、元素隔离、预加载、资源地址补全、插件系统、数据通信 等一系列完善的功能。

优点：

• 简单：只需一行代码，实现微前端，如此简单；
• 无关技术栈：任何框架皆可使用；
• 静态资源补全；
• JS沙箱；
• 样式隔离；
• Qiankun 微前端框架的优势他都有；

4. EMP

EMP 是欢聚时代基于 Webpack5 Module Federation 搭建的微前端方案；

由于是基于 Webpack5 Module Federation 来搭建的，所以相对与微前端跨框架、状态解决方案混淆比较严重，且 EMP 解决的是项目解耦而不是多系统聚合，与 bit（下面讲的） 这种跨项目组件复用平台较为类似；

优点：

• 依赖自动管理，可以共享 Host 中的依赖，版本不满足要求时自动 fallback 到 Remote 中依赖；
• 共享模块粒度自由掌控，小到一个单独组件，大到一个完整应用。既实现了组件级别的复用，又实现了微服务的基本功能；
• 共享模块非常灵活，模块中所有组件都可以通过异步加载调用；

缺点：

• 无法做到多框架兼容等微前端方案的痛点；
• 基于 Webpack5 Module Federation，需要统一 Webpack5 技术；
• 文档资料，社区不够活跃；

5. Garfish

Garfish 是由字节跳动开源的一套微前端解决方案，主要用于解决现代 web 应用在前端生态繁荣和 web 应用日益复杂化两大背景下带来的 跨团队协作、技术体系多样化、应用日益复杂化等问题，Garfish 已经经过大量的线上应用的打磨和测试，功能稳定可靠。

框架特性：

• 丰富高效的产品特征
• Garfish 微前端子应用支持任意多种框架、技术体系接入
• Garfish 微前端子应用支持「独立开发」、「独立测试」、「独立部署」
• 强大的预加载能力，自动记录用户应用加载习惯增加加载权重，应用切换时间极大缩短
• 支持依赖共享，极大程度的降低整体的包体积，减少依赖的重复加载
• 内置数据收集，有效的感知到应用在运行期间的状态
• 支持多实例能力，可在页面中同时运行多个子应用提升了业务的拆分力度
• 高扩展性的核心模块
• 通过 Loader 核心模块支持 HTML entry、JS entry 的支持，接入微前端应用简单易用
• Router 模块提供了路由驱动、主子路由隔离，用户仅需要配置路由表应用即可完成自主的渲染和销毁，无需关心内部逻辑
• Sandbox 模块为应用的 Runtime 提供运行时隔离能力，能有效隔离 JS、Style 对应用的副作用影响
• Store 提供了一套简单的通信数据交换机制
• 高度可扩展的插件机制
• 提供业务插件满足各种定制需求

设计理念：

另外字节跳动开源的号称「现代 Web 工程体系」的 modern.js 也是解决微前端的一个框架，大家感兴趣的可以去官网查看，因为该框架是一整套工程体系解决方案，所以可酌情选择；

6. Bit

由国外 bit 开发团队开源的一款跨项目的组件复用平台框架；将独立的组件构建、集成组合到一起去管理；

优点：

• 具有传统单体式前端的安全性和健壮性；
• 介接入方式简单、可伸缩性强；
• 通过 简单的解耦代码库、自治团队、小型定义良好的 API、独立的发布管道 和 持续增量升级，增强工作流程；

严格意义上来讲 Bit 与微前端有较大的的出入，所以 Bit 较为适合那种使用组件来开发项目，且技术栈较为统一的项目；

7. Liugi

Liugi 是国外 SAP 团队开源的一个用于微前端 JavaScript 框架；

Luigi 框架提供了配置选项、API 函数和开箱即用的功能，使迁移到微前端架构更容易。Luigi 为您的所有微前端提供一致的用户导航，确保更好的用户体验。

优点：

• 面向未来且可扩展；
• 无关技术栈：任何框架皆可使用；
• 独立团队管理、部署、研发；
• 快速部署新功能和错误修复；
• 更小、更易于管理的代码库；
• 降低维护成本；

8. OC（OpenComponent）

Open Component（简称 OC）项目宣布其目标是 前端世界中的无服务器。

更具体地说，OC 旨在成为一个 一站式微前端框架，从而使其成为一个丰富而复杂的系统，其中包括从组件处理到注册表、再到模板、甚至包括 CLI 工具。

OpenComponents 有两个部分：

• components 是同构代码的小单元，主要由 html、javascript、css 组成。它们可以选择包含一些逻辑，从而允许服务端的 node.js 应用去组建用于呈现视图的模型。在渲染之后，它们就是纯 html 片段，可以插入到任何 html 页面中。
• consumers 是网站或微型网站（所有小型可独立部署的网站，这些网站均通过前门服务或路由机制连接）。这些网站需要在其网页中呈现部分内容的组件。

9. Piral

Piral 是国外 smapiot 团队研发的一款基于 React 的微前端解决方案，其可以无限制地扩展开发工作、渐进部署并基于无服务器基础架构。

其定义了两个概念：

• 一个是 Piral，这是给一个应用的壳子（application shell），其承载着各种应用，当然也包括由pilets构建共享的组件，定义这些应用何时被加载以及何时被集成；
• 另一个是 Pilet，这是一个特殊的模块（feature modules），其承载着不同的一应用，包含着独立的资源，其决定了组件的加载时机。

优点：

• 高度模块化
• 多框架兼容
• 支持资源文件的拆分
• 全局状态管理
• 独立开发和部署
• CLI工具

相较于国外其它微前端框架，Piral 有更好的社区，文档，团队，如果你还在思考使用哪种微前端框架，Piral 不失为一个不错的选择；

10. 其它需要了解的框架

• Ara Framework：Ara Framework 是一个使用 Airbnb 的 Hypernova 服务端渲染延伸出的微前端框架，使用会较于局限；
• Mooa：Mooa 是一个为 Angular 服务的微前端框架，酌情考虑；
• ngx-planet：只支持 Angular 框架，不支持其他 MV* 前端框架，酌情考虑；
• PuzzleJs：PuzzleJs 是一个用于可扩展和快速建站的微前端框架。除了 SEO ，它的文档等 demo 都不成熟，酌情考虑；

当然以上只是概述了一些比较常见的微前端框架，还有一些较为优秀且开源的，欢迎大家补充；

• 如果你的项目是一个后台管理系统且都是最新的 MV* 框架，那么 Qiankun、Micro App、Garfish、Liugi、Piral 你都可以选择；
• 如果你的项目需要聚合某些老旧框架（jQuery）的项目，那么 Qiankun、MicroApp 都可选择，可优先考虑 Micro App；
• 如果你想做一个 SEO 的微前端项目，那么 Piral、PuzzleJs 较为适合；

当然，其实无论哪种方案都可选择其中的较为符合的框架，但是为了满足自己项目与业务场景，可能需要自己一个一个去踩坑才能实现了。

最后

最后说一句：用新技术，更多的不是因为先进，而是适合。

该系列是一个由浅入深让你从微前端的 选型、定型、造型 三个方面出发，全面深入了解微前端的 原理及理念，如何搞定一个企业级微前端服务从提出到落地的专栏；

感兴趣的朋友可以关注我的专栏《微前端从入门到进阶》，想与更多前端大佬交流，可以进入我的掘金主页加 vx 吹水；

总结

关于前端基建，在每个公司基建部分都会有所差异，有纯自动化一条龙的，有半自动化的等等；

但是如果我们细心的会发现，在几乎所有大中厂中，基建部分都不会少了 前端规范、前端文档、前端脚手架、前端组件库、前端工具库，所以如果实在是公司资源与业务限制，这几个还是值得去一探究竟的。

其实很多公司基建都不是一触而蹴的，基本上都是在常年累月的业务当中去 发现问题，定位问题，最后解决问题，然后在这个过程当中自然而然的沉淀出前端各个面向的基础设施，团队成员也会在这个过程当中找到适合自己的前端领域，并且深耕下去。

该系列会是一个持续更新系列，关于 前端基建，笔者主要会从如下图几个方面讲解，如果您想第一时间看到我的更新文章，可以关注我和我的《前端要搞基建》专栏

最后

关注我，带您一起搞基建 ~