1.冗餘依賴關系。
每個微前端應用程序都是獨立於其他應用程序的。換句話說，微前端架構涉及一個以上的前端應用程序，它們也應該能夠在沒有其他應用程序的情況下工作。為了實現這一點，他們每個人都有自己的依賴關系。所以，一般來說，你會失去使用包管理器的好處。事實上，您的整個應用程序可能由許多版本的相同庫組成，分散在每個微前端。
這無疑是一個問題，因為它使你的網絡應用比它的單個對應器更不必要。它落在終端用戶身上，他們被迫下載更多的數據。此外，它還會影響渲染時間，從而影響穀歌的分數和你網站的SEO。
如何解決這個問題。
一個可能的解決方案包括三個步驟。首先，確定所有微前端的通用數據庫。第二，創建一個包含所有共享數據庫的微前端。然後更新您的微前端，從共享項目中導入所需的數據庫。
正如Martin Fowler的原始博客所描述的，這個想法來自於應用之間的共享和依賴，這帶來了許多障礙，不能被視為一項容易完成的任務。所以，當你試圖實現這個目標時，請記住這一點。
2.沖突與重疊的風格。
同樣，技術和團隊的獨立性也很好，但它也會帶來一些問題。這在處理風格問題時尤其如此。事實上，從商業的角度來看，每個微前端都不能有自己的風格。當然，你不希望你的應用看起來像很多補丁。無論是風格、用戶界面還是用戶體驗，一切都應該看起來一致。
另一個問題是，作為同一應用程序的一部分，多個前端最終可能會無意中覆蓋CSS規則。CSS意外重疊在處理微前端時很常見，在部署應用程序後可能會找到它們。原因是每個團隊通常只在自己的應用程序上工作，在部署之前沒有看到整個圖片。
這些問題會對你的品牌聲譽產生負面影響。另外，終端用戶會為這些不一致的地方付出代價，尤其是在用戶界面。
如何解決這個問題。
當涉及到UI和UX時，唯一可能的解決方案是確保每個團隊相互交談，並考慮相同的結果。此外，在上述共享微前端項目中添加樣式組件也有幫助。然而，這將使每個微前端應用程序都依賴它，從而破壞底層的獨立性。但至少它會避免你的應用程序作為一個整體看起來異構。
一個解決方案是在前端容器中添加一個ID，以避免CSS重疊。
然後，在每個CSS規則之前，配置webpack插入此ID。否則，您可以決定使用CSS方法，如BEM(Block-Element-Modifier)。這鼓勵你將網站視為可重用組件的集合，其類名應該是您項目中唯一的。
3.性能差。
Javascript前端應用程序的速度在同一頁面上運行。這是因為每個框架實例都需要CpU、內存和網絡帶寬資源。
另外，請記住，當你的微前端與他人隔離時，你可能不會注意到這一點。當一個框架的多個例子同時運行時，問題開始了。這是因為，如果它們獨立運行，就不必像部署時那樣分享底層機器的資源。
如何解決這個問題。
解決這個問題的一個想法是加強團隊溝通，避免同樣的呼叫和解釋。然後，將其結果存儲在每個微前端可訪問的地方，或在執行繁重操作之前進行溝通，以驗證之前是否檢索或生成相同的數據光纖入屋拉線。
此外，當涉及到性能時，你必須使用所有的微前端來測試應用程序，而不僅僅是依靠每個微前端的測試。
4.前端之間的通信。
一開始，你不需要讓你的微前端通信，除非很少。這可能會愚弄你，讓你認為它會一直這樣。此外，雖然微前端的架構模式是關於獨立性的，但與通信相比。
當應用程序作為一個整體增長時，你的微前端可以毫不費力地相互交流。最重要的是，如果你想重複同樣的操作，尤其是當它們不是空閑的時候。
此外，為了實現更高的性能，有必要進行溝通。例如，您不希望您的應用程序調用相同的應用程序兩次，以檢索相同的數據，而不會減慢您的服務器。
如何解決這個問題。
解決方案是基於存儲在cokie或localstorage中的共享狀態，或基於自定義事件的自定義信息傳輸層。正如你所想，實現這一點是有成本的，很快就會變得複雜和麻煩，難以處理。此外，考慮到通信將引入成本。因此，你必須確保你所建立的東西會帶來真正的好處，而不讓你的應用程序變慢。
5.團隊之間的溝通。
大團隊之間的溝通可能是個問題，但最糟糕的是幾個團隊之間的溝通。這是因為許多團隊在不同的代碼庫中工作意味著更難找到可重用的功能、函數和實用程序。這在代碼的可發現性方面非常糟糕，因此也可重用。換句話說，同樣的組件很容易在不同的微觀前台重複。
精選文章：
