微前端開發(fā)常見問題匯總，前端應(yīng)用可以獨(dú)立運(yùn)行、獨(dú)立開發(fā)、獨(dú)立部署。微前端不是單純的前端框架或者工具而是一套架構(gòu)體系。其在開發(fā)中會有各種問題，今天小編整理了一下分享給大家!

1、微前端只是Web端

為什么只是Web?到目前為止我們接觸到的主要是Web，但其概念和想法可以應(yīng)用于任何類型的應(yīng)用程序(移動應(yīng)用、客戶端應(yīng)用……甚至是CLI工具)微前端只是“插件架構(gòu)”的一個(gè)花哨叫法。不過，插件接口如何設(shè)計(jì)，以及運(yùn)行使用插件的應(yīng)用程序需要具備什么條件就是另外一回事了。 如圖一個(gè)非常通用的插件架構(gòu)(來源：OmarElgabry)

該架構(gòu)并沒有在哪里運(yùn)行的概念。既可以在手機(jī)上運(yùn)行，也能在Windows上運(yùn)行，甚至還能在服務(wù)器上運(yùn)行。

2、微前端需要大型團(tuán)隊(duì)

如果解決方案超級復(fù)雜，那么我肯定會找一個(gè)簡單的。有些問題需要復(fù)雜的解決方案，但好的解決方案通常是簡單的。 根據(jù)場景的不同，甚至可能不需要一個(gè)分布式團(tuán)隊(duì)。擁有分布式團(tuán)隊(duì)是采用微前端的首要原因之一，但不是唯一原因。另一個(gè)很好的理由是特性的粒度。

如果從業(yè)務(wù)的角度來看微前端，那么你就會發(fā)現(xiàn)，擁有啟用和關(guān)閉特定特性的能力是很有意義的。針對不同的市場，使用不同的微前端。回到一個(gè)簡單的權(quán)限模式，這是有意義的。不需要編寫代碼來根據(jù)特定條件打開或關(guān)閉某些東西。所有這些都留給公共層，可以根據(jù)(可能是動態(tài)的)條件激活或停用。

不能或不應(yīng)該使用的代碼也不會被交付。雖然這不應(yīng)該是一個(gè)保護(hù)層，但肯定是一個(gè)便捷和性能層。用戶不會感到困惑，因?yàn)樗麄兛吹降氖撬麄兡茏龅摹Ｋ麄兛床坏經(jīng)]有交付的功能，所以沒有字節(jié)浪費(fèi)在不可用的代碼上。

3、微前端無法調(diào)試

對于任何類型的實(shí)現(xiàn)(或供討論的底層架構(gòu))，開發(fā)經(jīng)驗(yàn)都可能遭到削弱。應(yīng)對這種情況的唯一方法是開發(fā)人員優(yōu)先。實(shí)現(xiàn)中的第一原則應(yīng)該是：使調(diào)試和開發(fā)成為可能。采用標(biāo)準(zhǔn)的工具。有些微前端框架根本不接受這一點(diǎn)。有些需要在線連接、專用環(huán)境、多重服務(wù)等，這不應(yīng)該是標(biāo)準(zhǔn)也絕不是常態(tài)。

4、微服務(wù)需要微前端(或反過來)

解耦的模塊化后端可能為解耦前端打下了一個(gè)很好的基礎(chǔ)，但通常情況下，情況并非如此。后端單體，前端模塊化，也是完全可行的，例如，為簡化個(gè)性化可能就要結(jié)合授權(quán)、權(quán)限和市場。 同樣，微服務(wù)后端并不能證明適合將類似的模式應(yīng)用于前端。許多微服務(wù)后端都是由單用途的應(yīng)用程序操作的，們的功能沒有增加，只是外觀發(fā)生了改變。

5、微前端需要單存儲庫

要創(chuàng)建一個(gè)微前端解決方案，就需要利用單存儲庫，最好使用像Lerna這樣的工具。我不認(rèn)可這一點(diǎn)。當(dāng)然，單存儲庫有一些優(yōu)點(diǎn)，但也有明顯的缺點(diǎn)。雖然有一些微前端框架需要聯(lián)合CI/CD構(gòu)建，但大多數(shù)都不需要。聯(lián)合CI/CD構(gòu)建通常會導(dǎo)致單存儲庫，因?yàn)槠湓O(shè)置要簡單得多。但對我來說，這是單體重新打包。如果你在單存儲庫上進(jìn)行聯(lián)合構(gòu)建，那么你就失去了讓微前端富有吸引力的兩個(gè)非常重要的優(yōu)點(diǎn)獨(dú)立部署和獨(dú)立開發(fā)

如果你看到微前端解決方案需要單存儲庫：那樣做就行。一個(gè)精心設(shè)計(jì)的單體系統(tǒng)可能會更好，不會有分布式系統(tǒng)的所有問題。

以上就是關(guān)于微前端開發(fā)常見問題和誤區(qū)的介紹希望能幫到您。