文就某一個(gè)具體的類(lèi)型場(chǎng)景，著重介紹微前端架構(gòu)可以帶來(lái)什么價(jià)值以及具體實(shí)踐過(guò)程中需要關(guān)注的技術(shù)決策，并輔以具體代碼，從而幫助讀者構(gòu)建一個(gè)生產(chǎn)可用的微前端架構(gòu)系統(tǒng)。

Techniques, strategies and recipes for building a modern web app with multiple teams using different JavaScript frameworks. — Micro Frontends

前言

目前社區(qū)有很多關(guān)于微前端架構(gòu)的介紹，但大多停留在概念介紹的階段。而本文會(huì)就某一個(gè)具體的類(lèi)型場(chǎng)景，著重介紹微前端架構(gòu)可以帶來(lái)什么價(jià)值以及具體實(shí)踐過(guò)程中需要關(guān)注的技術(shù)決策，并輔以具體代碼，從而能真正意義上幫助你構(gòu)建一個(gè)生產(chǎn)可用的微前端架構(gòu)系統(tǒng)。

而對(duì)于微前端的概念感興趣或不熟悉的同學(xué)，可以通過(guò)搜索引擎來(lái)獲取更多信息，如 知乎上的相關(guān)內(nèi)容， 本文不再做過(guò)多介紹。

• 兩個(gè)月前 Twitter 曾爆發(fā)過(guò)關(guān)于微前端的“熱烈”討論，參與大佬眾多 (Dan、Larkin 等)，對(duì)“事件”本身我們今天不做過(guò)多評(píng)論 (后面可能會(huì)寫(xiě)篇文章來(lái)回顧一下)，有興趣的同學(xué)可以通過(guò)這篇文章了解一二：
• https://zendev.com/2019/06/17/microfrontends-good-bad-ugly.html

微前端的價(jià)值

微前端架構(gòu)具備以下幾個(gè)核心價(jià)值：

• 技術(shù)棧無(wú)關(guān)
• 主框架不限制接入應(yīng)用的技術(shù)棧，子應(yīng)用具備完全自主權(quán)。
• 獨(dú)立開(kāi)發(fā)、獨(dú)立部署
• 子應(yīng)用倉(cāng)庫(kù)獨(dú)立，前后端可獨(dú)立開(kāi)發(fā)，部署完成后主框架自動(dòng)完成同步更新。
• 獨(dú)立運(yùn)行時(shí)
• 每個(gè)子應(yīng)用之間狀態(tài)隔離，運(yùn)行時(shí)狀態(tài)不共享。

微前端架構(gòu)旨在解決單體應(yīng)用在一個(gè)相對(duì)長(zhǎng)的時(shí)間跨度下，由于參與的人員、團(tuán)隊(duì)的增多、變遷，從一個(gè)普通應(yīng)用演變成一個(gè)巨石應(yīng)用 (Frontend Monolith) 后，隨之而來(lái)的應(yīng)用不可維護(hù)的問(wèn)題。這類(lèi)問(wèn)題在企業(yè)級(jí) Web 應(yīng)用中尤其常見(jiàn)。

針對(duì)中后臺(tái)應(yīng)用的解決方案

中后臺(tái)應(yīng)用由于其應(yīng)用生命周期長(zhǎng) (動(dòng)輒 3+ 年) 等特點(diǎn)，最后演變成一個(gè)巨石應(yīng)用的概率往往高于其他類(lèi)型的 web 應(yīng)用。而從技術(shù)實(shí)現(xiàn)角度，微前端架構(gòu)解決方案大概分為兩類(lèi)場(chǎng)景：

• 單實(shí)例：即同一時(shí)刻，只有一個(gè)子應(yīng)用被展示，子應(yīng)用具備一個(gè)完整的應(yīng)用生命周期。通?；?url 的變化來(lái)做子應(yīng)用的切換。
• 多實(shí)例：同一時(shí)刻可展示多個(gè)子應(yīng)用。通常使用 Web Components 方案來(lái)做子應(yīng)用封裝，子應(yīng)用更像是一個(gè)業(yè)務(wù)組件而不是應(yīng)用。

本文將著重介紹單實(shí)例場(chǎng)景下的微前端架構(gòu)實(shí)踐方案（基于 single-spa），因?yàn)檫@個(gè)場(chǎng)景更貼近大部分中后臺(tái)應(yīng)用。

行業(yè)現(xiàn)狀

傳統(tǒng)的云控制臺(tái)應(yīng)用，幾乎都會(huì)面臨業(yè)務(wù)快速發(fā)展之后，單體應(yīng)用進(jìn)化成巨石應(yīng)用的問(wèn)題。為了解決產(chǎn)品研發(fā)之間各種耦合的問(wèn)題，大部分企業(yè)也都會(huì)有自己的解決方案。筆者于 17 年底，針對(duì)國(guó)內(nèi)外幾個(gè)著名的云產(chǎn)品控制臺(tái)，做過(guò)這樣一個(gè)技術(shù)調(diào)研：

MPA 方案的優(yōu)點(diǎn)在于部署簡(jiǎn)單、各應(yīng)用之間硬隔離，天生具備技術(shù)棧無(wú)關(guān)、獨(dú)立開(kāi)發(fā)、獨(dú)立部署的特性。缺點(diǎn)則也很明顯，應(yīng)用之間切換會(huì)造成瀏覽器重刷，由于產(chǎn)品域名之間相互跳轉(zhuǎn)，流程體驗(yàn)上會(huì)存在斷點(diǎn)。

SPA 則天生具備體驗(yàn)上的優(yōu)勢(shì)，應(yīng)用直接無(wú)刷新切換，能極大的保證多產(chǎn)品之間流程操作串聯(lián)時(shí)的流程性。缺點(diǎn)則在于各應(yīng)用技術(shù)棧之間是強(qiáng)耦合的。

那我們有沒(méi)有可能將 MPA 和 SPA 兩者的優(yōu)勢(shì)結(jié)合起來(lái)，構(gòu)建出一個(gè)相對(duì)完善的微前端架構(gòu)方案呢？

JSConf China 2016 大會(huì)上，ucloud 的同學(xué)分享了他們的基于 angularjs 的方案（單頁(yè)應(yīng)用“聯(lián)邦制”實(shí)踐），里面提到的 "聯(lián)邦制" 概念很貼切，可以認(rèn)為是早期的基于耦合技術(shù)棧的微前端架構(gòu)實(shí)踐。

微前端架構(gòu)實(shí)踐中的問(wèn)題

可以發(fā)現(xiàn)，微前端架構(gòu)的優(yōu)勢(shì)，正是 MPA 與 SPA 架構(gòu)優(yōu)勢(shì)的合集。即保證應(yīng)用具備獨(dú)立開(kāi)發(fā)權(quán)的同時(shí)，又有將它們整合到一起保證產(chǎn)品完整的流程體驗(yàn)的能力。

這樣一套模式下，應(yīng)用的架構(gòu)就會(huì)變成：

Stitching layer 作為主框架的核心成員，充當(dāng)調(diào)度者的角色，由它來(lái)決定在不同的條件下激活不同的子應(yīng)用。因此主框架的定位則僅僅是：導(dǎo)航路由 + 資源加載框架。

而具體要實(shí)現(xiàn)這樣一套架構(gòu)，我們需要解決以下幾個(gè)技術(shù)問(wèn)題：

路由系統(tǒng)及 Future State

我們?cè)谝粋€(gè)實(shí)現(xiàn)了微前端內(nèi)核的產(chǎn)品中，正常訪問(wèn)一個(gè)子應(yīng)用的頁(yè)面時(shí)，可能會(huì)有這樣一個(gè)鏈路：

由于我們的子應(yīng)用都是 lazy load 的，當(dāng)瀏覽器重新刷新時(shí)，主框架的資源會(huì)被重新加載，同時(shí)異步 load 子應(yīng)用的靜態(tài)資源，由于此時(shí)主應(yīng)用的路由系統(tǒng)已經(jīng)激活，但子應(yīng)用的資源可能還沒(méi)有完全加載完畢，從而導(dǎo)致路由注冊(cè)表里發(fā)現(xiàn)沒(méi)有能匹配子應(yīng)用 /subApp/123/detail 的規(guī)則，這時(shí)候就會(huì)導(dǎo)致跳 NotFound 頁(yè)或者直接路由報(bào)錯(cuò)。

這個(gè)問(wèn)題在所有 lazy load 方式加載子應(yīng)用的方案中都會(huì)碰到，早些年前 angularjs 社區(qū)把這個(gè)問(wèn)題統(tǒng)一稱(chēng)之為 Future State: https://ui-router.github.io/guide/lazyloading#future-states

解決的思路也很簡(jiǎn)單，我們需要設(shè)計(jì)這樣一套路由機(jī)制：

主框架配置子應(yīng)用的路由為 subApp: { url: '/subApp/**', entry: './subApp.js' }，則當(dāng)瀏覽器的地址為 /subApp/abc 時(shí)，框架需要先加載 entry 資源，待 entry 資源加載完畢，確保子應(yīng)用的路由系統(tǒng)注冊(cè)進(jìn)主框架之后后，再去由子應(yīng)用的路由系統(tǒng)接管 url change 事件。同時(shí)在子應(yīng)用路由切出時(shí)，主框架需要觸發(fā)相應(yīng)的 destroy 事件，子應(yīng)用在監(jiān)聽(tīng)到該事件時(shí)，調(diào)用自己的卸載方法卸載應(yīng)用，如 React 場(chǎng)景下 destroy=()=> ReactDOM.unmountAtNode(container)。

要實(shí)現(xiàn)這樣一套機(jī)制，我們可以自己去劫持 url change 事件從而實(shí)現(xiàn)自己的路由系統(tǒng)，也可以基于社區(qū)已有的 ui router library，尤其是 react-router 在 v4 之后實(shí)現(xiàn)了 Dynamic Routing 能力，我們只需要復(fù)寫(xiě)一部分路由發(fā)現(xiàn)的邏輯即可。這里我們推薦直接選擇社區(qū)比較完善的相關(guān)實(shí)踐 single-spa。

App Entry

解決了路由問(wèn)題后，主框架與子應(yīng)用集成的方式，也會(huì)成為一個(gè)需要重點(diǎn)關(guān)注的技術(shù)決策。

構(gòu)建時(shí)組合 VS 運(yùn)行時(shí)組合

微前端架構(gòu)模式下，子應(yīng)用打包的方式，基本分為兩種：

兩者的優(yōu)缺點(diǎn)也很明顯：

很顯然，要實(shí)現(xiàn)真正的技術(shù)棧無(wú)關(guān)跟獨(dú)立部署兩個(gè)核心目標(biāo)，大部分場(chǎng)景下我們需要使用運(yùn)行時(shí)加載子應(yīng)用這種方案。

JS Entry vs HTML Entry

在確定了運(yùn)行時(shí)載入的方案后，另一個(gè)需要決策的點(diǎn)是，我們需要子應(yīng)用提供什么形式的資源作為渲染入口？

JS Entry 的方式通常是子應(yīng)用將資源打成一個(gè) entry script，比如 single-spa 的 example 中的方式。但這個(gè)方案的限制也頗多，如要求子應(yīng)用的所有資源打包到一個(gè) js bundle 里，包括 css、圖片等資源。除了打出來(lái)的包可能體積龐大之外的問(wèn)題之外，資源的并行加載等特性也無(wú)法利用上。

HTML Entry 則更加靈活，直接將子應(yīng)用打出來(lái) HTML 作為入口，主框架可以通過(guò) fetch html 的方式獲取子應(yīng)用的靜態(tài)資源，同時(shí)將 HTML document 作為子節(jié)點(diǎn)塞到主框架的容器中。這樣不僅可以極大的減少主應(yīng)用的接入成本，子應(yīng)用的開(kāi)發(fā)方式及打包方式基本上也不需要調(diào)整，而且可以天然的解決子應(yīng)用之間樣式隔離的問(wèn)題 (后面提到)。想象一下這樣一個(gè)場(chǎng)景：

<!-- 子應(yīng)用 index.html -->
<script src="http://unpkg/antd.min.js"></script>
<body>
 <main id="root"></main>
</body>
// 子應(yīng)用入口
ReactDOM.render(<App/>, document.getElementById('root'))

如果是 JS Entry 方案，主框架需要在子應(yīng)用加載之前構(gòu)建好相應(yīng)的容器節(jié)點(diǎn) (比如這里的 "#root" 節(jié)點(diǎn))，不然子應(yīng)用加載時(shí)會(huì)因?yàn)檎也坏?container 報(bào)錯(cuò)。但問(wèn)題在于，主應(yīng)用并不能保證子應(yīng)用使用的容器節(jié)點(diǎn)為某一特定標(biāo)記元素。而 HTML Entry 的方案則天然能解決這一問(wèn)題，保留子應(yīng)用完整的環(huán)境上下文，從而確保子應(yīng)用有良好的開(kāi)發(fā)體驗(yàn)。

HTML Entry 方案下，主框架注冊(cè)子應(yīng)用的方式則變成：

framework.registerApp('subApp1', { entry: '//abc.alipay.com/index.html'})

本質(zhì)上這里 HTML 充當(dāng)?shù)氖菓?yīng)用靜態(tài)資源表的角色，在某些場(chǎng)景下，我們也可以將 HTML Entry 的方案優(yōu)化成 Config Entry，從而減少一次請(qǐng)求，如：

framework.registerApp('subApp1', { html: '', scripts: ['//abc.alipay.com/index.js'], css: ['//abc.alipay.com/index.css']})

總結(jié)一下：

模塊導(dǎo)入

微前端架構(gòu)下，我們需要獲取到子應(yīng)用暴露出的一些鉤子引用，如 bootstrap、mount、unmout 等 (參考 single-spa)，從而能對(duì)接入應(yīng)用有一個(gè)完整的生命周期控制。而由于子應(yīng)用通常又有集成部署、獨(dú)立部署兩種模式同時(shí)支持的需求，使得我們只能選擇 umd 這種兼容性的模塊格式打包我們的子應(yīng)用。如何在瀏覽器運(yùn)行時(shí)獲取遠(yuǎn)程腳本中導(dǎo)出的模塊引用也是一個(gè)需要解決的問(wèn)題。

通常我們第一反應(yīng)的解法，也是最簡(jiǎn)單的解法就是與子應(yīng)用與主框架之間約定好一個(gè)全局變量，把導(dǎo)出的鉤子引用掛載到這個(gè)全局變量上，然后主應(yīng)用從這里面取生命周期函數(shù)。

這個(gè)方案很好用，但是最大的問(wèn)題是，主應(yīng)用與子應(yīng)用之間存在一種強(qiáng)約定的打包協(xié)議。那我們是否能找出一種松耦合的解決方案呢？

很簡(jiǎn)單，我們只需要走 umd 包格式中的 global export 方式獲取子應(yīng)用的導(dǎo)出即可，大體的思路是通過(guò)給 window 變量打標(biāo)記，記住每次最后添加的全局變量，這個(gè)變量一般就是應(yīng)用 export 后掛載到 global 上的變量。實(shí)現(xiàn)方式可以參考 systemjs global import，這里不再贅述，相關(guān)鏈接: https://github.com/systemjs/systemjs/blob/master/src/extras/global.js

應(yīng)用隔離

微前端架構(gòu)方案中有兩個(gè)非常關(guān)鍵的問(wèn)題，有沒(méi)有解決這兩個(gè)問(wèn)題將直接標(biāo)志你的方案是否真的生產(chǎn)可用。比較遺憾的是此前社區(qū)在這個(gè)問(wèn)題上的處理都會(huì)不約而同選擇”繞道“的方式，比如通過(guò)主子應(yīng)用之間的一些默認(rèn)約定去規(guī)避沖突。而今天我們會(huì)嘗試從純技術(shù)角度，更智能的解決應(yīng)用之間可能沖突的問(wèn)題。

樣式隔離

由于微前端場(chǎng)景下，不同技術(shù)棧的子應(yīng)用會(huì)被集成到同一個(gè)運(yùn)行時(shí)中，所以我們必須在框架層確保各個(gè)子應(yīng)用之間不會(huì)出現(xiàn)樣式互相干擾的問(wèn)題。

• Shadow DOM？

針對(duì) "Isolated Styles" 這個(gè)問(wèn)題，如果不考慮瀏覽器兼容性，通常第一個(gè)浮現(xiàn)到我們腦海里的方案會(huì)是 Web Components?；?Web Components 的 Shadow DOM 能力，我們可以將每個(gè)子應(yīng)用包裹到一個(gè) Shadow DOM 中，保證其運(yùn)行時(shí)的樣式的絕對(duì)隔離。

但 Shadow DOM 方案在工程實(shí)踐中會(huì)碰到一個(gè)常見(jiàn)問(wèn)題，比如我們這樣去構(gòu)建了一個(gè)在 Shadow DOM 里渲染的子應(yīng)用：

const shadow=document.querySelector('#hostElement').attachShadow({mode: 'open'});
shadow.innerHTML='<sub-app>Here is some new text</sub-app><link rel="stylesheet" ;

由于子應(yīng)用的樣式作用域僅在 shadow 元素下，那么一旦子應(yīng)用中出現(xiàn)運(yùn)行時(shí)越界跑到外面構(gòu)建 DOM 的場(chǎng)景，必定會(huì)導(dǎo)致構(gòu)建出來(lái)的 DOM 無(wú)法應(yīng)用子應(yīng)用的樣式的情況。

比如 sub-app 里調(diào)用了 antd modal 組件，由于 modal 是動(dòng)態(tài)掛載到 document.body 的，而由于 Shadow DOM 的特性 antd 的樣式只會(huì)在 shadow 這個(gè)作用域下生效，結(jié)果就是彈出框無(wú)法應(yīng)用到 antd 的樣式。解決的辦法是把 antd 樣式上浮一層，丟到主文檔里，但這么做意味著子應(yīng)用的樣式直接泄露到主文檔了。

• CSS Module? BEM?

社區(qū)通常的實(shí)踐是通過(guò)約定 css 前綴的方式來(lái)避免樣式?jīng)_突，即各個(gè)子應(yīng)用使用特定的前綴來(lái)命名 class，或者直接基于 css module 方案寫(xiě)樣式。對(duì)于一個(gè)全新的項(xiàng)目，這樣當(dāng)然是可行，但是通常微前端架構(gòu)更多的目標(biāo)是解決存量 / 遺產(chǎn) 應(yīng)用的接入問(wèn)題。很顯然遺產(chǎn)應(yīng)用通常是很難有動(dòng)力做大幅改造的。

最主要的是，約定的方式有一個(gè)無(wú)法解決的問(wèn)題，假如子應(yīng)用中使用了三方的組件庫(kù)，三方庫(kù)在寫(xiě)入了大量的全局樣式的同時(shí)又不支持定制化前綴？比如 a 應(yīng)用引入了 antd 2.x，而 b 應(yīng)用引入了 antd 3.x，兩個(gè)版本的 antd 都寫(xiě)入了全局的 .menu class，但又彼此不兼容怎么辦？

• Dynamic Stylesheet !

解決方案其實(shí)很簡(jiǎn)單，我們只需要在應(yīng)用切出 / 卸載后，同時(shí)卸載掉其樣式表即可，原理是瀏覽器會(huì)對(duì)所有的樣式表的插入、移除做整個(gè) CSSOM 的重構(gòu)，從而達(dá)到 插入、卸載 樣式的目的。這樣即能保證，在一個(gè)時(shí)間點(diǎn)里，只有一個(gè)應(yīng)用的樣式表是生效的。

上文提到的 HTML Entry 方案則天生具備樣式隔離的特性，因?yàn)閼?yīng)用卸載后會(huì)直接移除去 HTML 結(jié)構(gòu)，從而自動(dòng)移除了其樣式表。

比如 HTML Entry 模式下，子應(yīng)用加載完成的后的 DOM 結(jié)構(gòu)可能長(zhǎng)這樣：

<html>
 <body>
 <main id="subApp">
 // 子應(yīng)用完整的 html 結(jié)構(gòu)
 <link rel="stylesheet" >
 <div id="root">....</div>
 </main>
 </body>
</html>

當(dāng)子應(yīng)用被替換或卸載時(shí)，subApp 節(jié)點(diǎn)的 innerHTML 也會(huì)被復(fù)寫(xiě)，//alipay.com/subapp.css 也就自然被移除樣式也隨之卸載了。

JS 隔離

解決了樣式隔離的問(wèn)題后，有一個(gè)更關(guān)鍵的問(wèn)題我們還沒(méi)有解決：如何確保各個(gè)子應(yīng)用之間的全局變量不會(huì)互相干擾，從而保證每個(gè)子應(yīng)用之間的軟隔離？

這個(gè)問(wèn)題比樣式隔離的問(wèn)題更棘手，社區(qū)的普遍玩法是給一些全局副作用加各種前綴從而避免沖突。但其實(shí)我們都明白，這種通過(guò)團(tuán)隊(duì)間的”口頭“約定的方式往往低效且易碎，所有依賴(lài)人為約束的方案都很難避免由于人的疏忽導(dǎo)致的線上 bug。那么我們是否有可能打造出一個(gè)好用的且完全無(wú)約束的 JS 隔離方案呢？

針對(duì) JS 隔離的問(wèn)題，我們獨(dú)創(chuàng)了一個(gè)運(yùn)行時(shí)的 JS 沙箱。簡(jiǎn)單畫(huà)了個(gè)架構(gòu)圖：

即在應(yīng)用的 bootstrap 及 mount 兩個(gè)生命周期開(kāi)始之前分別給全局狀態(tài)打下快照，然后當(dāng)應(yīng)用切出 / 卸載時(shí)，將狀態(tài)回滾至 bootstrap 開(kāi)始之前的階段，確保應(yīng)用對(duì)全局狀態(tài)的污染全部清零。而當(dāng)應(yīng)用二次進(jìn)入時(shí)則再恢復(fù)至 mount 前的狀態(tài)的，從而確保應(yīng)用在 remount 時(shí)擁有跟第一次 mount 時(shí)一致的全局上下文。

當(dāng)然沙箱里做的事情還遠(yuǎn)不止這些，其他的還包括一些對(duì)全局事件監(jiān)聽(tīng)的劫持等，以確保應(yīng)用在切出之后，對(duì)全局事件的監(jiān)聽(tīng)能得到完整的卸載，同時(shí)也會(huì)在 remount 時(shí)重新監(jiān)聽(tīng)這些全局事件，從而模擬出與應(yīng)用獨(dú)立運(yùn)行時(shí)一致的沙箱環(huán)境。

螞蟻的微前端落地實(shí)踐

自去年年底伊始，我們便嘗試基于微前端架構(gòu)模式，構(gòu)建出一套全鏈路的面向中后臺(tái)場(chǎng)景的產(chǎn)品接入平臺(tái)，目的是解決不同產(chǎn)品之間集成困難、流程割裂的問(wèn)題，希望接入平臺(tái)后的應(yīng)用，不論使用哪種技術(shù)棧，在運(yùn)行時(shí)都可以通過(guò)自定義配置，實(shí)現(xiàn)不同應(yīng)用之間頁(yè)面級(jí)別的自由組合，從而生成一個(gè)千人千面的個(gè)性化控制臺(tái)。

目前這套平臺(tái)已在螞蟻生產(chǎn)環(huán)境運(yùn)行半年多，同時(shí)接入了多個(gè)產(chǎn)品線的 40+ 應(yīng)用、4+ 不同類(lèi)型的技術(shù)棧。過(guò)程中針對(duì)大量微前端實(shí)踐中的問(wèn)題，我們總結(jié)出了一套完整的解決方案：

在內(nèi)部得到充分的技術(shù)驗(yàn)證和線上考驗(yàn)之后，我們決定將這套解決方案開(kāi)源出來(lái)！

qiankun - 一套完整的微前端解決方案

取名 qiankun，意為統(tǒng)一。我們希望通過(guò) qiankun 這種技術(shù)手段，讓你能很方便的將一個(gè)巨石應(yīng)用改造成一個(gè)基于微前端架構(gòu)的系統(tǒng)，并且不再需要去關(guān)注各種過(guò)程中的技術(shù)細(xì)節(jié)，做到真正的開(kāi)箱即用和生產(chǎn)可用。

對(duì)于 umi 用戶我們也提供了配套的 qiankun 插件 @umijs/plugin-qiankun ，以便于 umi 應(yīng)用能幾乎零成本的接入 qiankun。

qiankun 開(kāi)源: https://github.com/umijs/qiankun

@umijs/plugin-qiankun: https://github.com/umijs/umi-plugin-qiankun/

這里有一份獨(dú)家晉升指南：

部分VIP資料：

最后說(shuō)一下的，也就是以上教程的獲取方式！

領(lǐng)取方法：

還是以往不變的老規(guī)矩！

1.評(píng)論文章，沒(méi)字?jǐn)?shù)限制，一個(gè)字都行！然后轉(zhuǎn)發(fā)出去！

2.關(guān)注小編，成為小編的粉絲！

3.私信小編：“前端教程”即可！

通過(guò)申請(qǐng)后會(huì)逐個(gè)開(kāi)通權(quán)限，小助手精力有限，手慢無(wú)哦

視頻的價(jià)值取決于領(lǐng)取后的行動(dòng)，大家千萬(wàn)別做收藏黨。和志同道合的人一起深入討論與學(xué)習(xí) Web前端技術(shù)，也歡迎轉(zhuǎn)給需要的朋友！