本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 樣式和 CSS
層疊樣式表 (CSS) 是一種語言，用於集中判斷文件的呈現，而不是文字和物件的硬式編碼格式。語言的層疊功能旨在透過使用繼承來控制樣式之間的優先順序。當您處理微型前端並建立策略來管理相依性時，語言的層疊功能可能是一項挑戰。
例如，同一頁面上有兩個微型前端共存，每個都會為 `body` HTML 元素定義自己的樣式。如果每個 都擷取自己的 CSS 檔案，並使用`style`標籤將其連接至 DOM，則如果 CSS 檔案都具有常見 HTML 元素、類別名稱或元素 IDs的定義，則 CSS 檔案會覆寫至第一個。有不同的策略可以處理這些問題，取決於您為管理樣式選擇的相依性策略。
目前，在效能、一致性和開發人員體驗之間取得平衡的最熱門方法包括開發和維護設計系統。
## 設計系統 ‒ 共享方式
這種方法使用系統在適當的時候共用樣式，同時支援偶爾的分歧，以平衡一致性、效能和開發人員體驗。設計系統是由明確標準引導的可重複使用元件集合。設計系統開發通常由一個團隊驅動，其中包含來自許多團隊的輸入和貢獻。實際上，設計系統是一種共用低階元素的方法，可匯出為 JavaScript 程式庫。微型前端開發人員可以使用程式庫做為相依性，透過編寫預先製作的可用資源來建置簡單的介面，並做為建立新介面的起點。
考慮需要表單的微型前端範例。典型的開發人員體驗包括使用設計系統中可用的預先製作元件來編寫文字方塊、按鈕、下拉式清單和其他 UI 元素。開發人員不需要為實際元件撰寫任何樣式，僅針對它們的外觀。要建置和發行的系統可以使用 webpack Module Federation 或類似方法將設計系統宣告為外部相依性，以便封裝表單的邏輯，而不包含設計系統。
然後，多個微型前端可以執行相同的操作，以處理共用的考量。當團隊開發可在多個微型前端之間共用的新元件時，這些元件會在到期後新增至設計系統。
設計系統方法的主要優點是高度一致性。雖然微型前端可以撰寫樣式，並偶爾覆寫設計系統中的樣式，但幾乎不需要這麼做。主要低階元素不會經常變更，而且它們提供依預設可延伸的基本功能。另一個優點是效能。透過建置和發行的良好策略，您可以產生由應用程式 shell 檢測的最小共用套件。當多個微型前端特定套件以非同步方式隨需載入時，您可以進一步改善，且網路頻寬的佔用空間最少。最後，開發人員體驗是理想的，因為人們可以專注於建置豐富的界面，而無需重塑輪子 （例如，每次需要將按鈕新增到頁面時撰寫 JavaScript 和 CSS)。
缺點是任何類型的設計系統都是相依性，因此必須加以維護，有時會更新。如果多個微型前端需要共用相依性的新版本，您可以使用下列其中一項：
+ 一種協同運作機制，可偶爾擷取該共用相依性的多個版本，而不會發生衝突
+ 移動所有相依項目以使用新版本的共用策略
例如，如果所有微型前端都依賴於設計系統的 3.0 版，並且有名為 3.1 的新版本以共用方式使用，您可以實作功能旗標，讓所有微型前端遷移並降低風險。如需詳細資訊，請參閱[功能旗標](feature-flags.md)一節。另一個潛在的缺點是，設計系統通常不只處理樣式。它們也包含 JavaScript 實務和工具。這些層面需要透過爭論和協作達成共識。
實作設計系統是良好的長期投資。這是一種熱門的方法，任何處理複雜前端架構的人都應考慮。它通常需要前端工程師和產品和設計團隊來協作和定義相互互動的機制。請務必排定到達所需狀態的時間。獲得領導層的贊助也很重要，以便人們可以長期建立可靠、維護良好且效能良好的項目。
## 完全封裝的 CSS ‒ 不共享方法
每個微型前端都使用慣例和工具來克服 CSS 的層疊功能。一個範例是確保每個元素的樣式一律與類別名稱相關聯，而不是元素的 ID，而且類別名稱一律是唯一的。以這種方式，一切都範圍限定於個別微型前端，並將不必要的衝突風險降至最低。應用程式殼層通常負責在載入 DOM 之後載入微型前端的樣式，但有些工具會使用 JavaScript 將樣式綁定在一起。
不共用內容的主要優點是降低在微型前端之間引入衝突的風險。另一個優點是開發人員的體驗。每個微型前端不會與其他微型前端共用任何內容。獨立發佈和測試更為簡單快速。
共享方法的主要缺點是可能缺乏一致性。沒有系統可評估一致性。即使複製共用的內容是目標，在平衡發行和協同合作的速度時也會變得具有挑戰性。常見的緩解措施是建立工具來測量一致性。例如，您可以建立一個系統，使用無頭瀏覽器擷取頁面中呈現的多個微型前端的自動螢幕擷取畫面。然後，您可以在發行之前手動檢閱螢幕擷取畫面。不過，這需要紀律和控管。如需詳細資訊，請參閱[搭配對齊的平衡自主性](balance-autonomy-alignment.md)一節。
根據使用案例，另一個潛在的缺點是效能。如果所有微型前端都使用大量樣式，客戶必須下載大量重複的程式碼。這將對使用者體驗產生負面影響。
只有涉及幾個團隊的微型前端架構，或可容忍低一致性的微型前端，才應考慮此共用方法。當組織在設計系統上工作時，它也可以是自然的初始步驟。
## 共享全域 CSS ‒ 共享全的方法
透過此方法，所有與樣式相關的程式碼都存放在中央儲存庫中，其中參與者透過處理 CSS 檔案或使用預處理器，例如 Sass，為所有微型前端撰寫 CSS。進行變更時，建置系統會建立單一 CSS 套件，以託管在 CDN 中，並包含在應用程式 Shell 的每個微型前端中。微型前端開發人員可以透過本機託管的應用程式 shell 執行程式碼，來設計和建置其應用程式。
除了降低微型前端之間衝突風險的明顯優勢之外，這種方法的優勢是一致性和效能。不過，從標記和邏輯解耦樣式會讓開發人員更難了解樣式的使用方式、演進方式，以及取代方式。例如，引入新的類別名稱可能比了解現有類別以及編輯其屬性的後果更快。建立新類別名稱的缺點是套件大小成長，這會影響效能，以及在使用者體驗中潛在引入不一致。
雖然共用的全域 CSS 可以作為monolith-to-micro-frontends遷移的起點，但對於涉及超過一個或兩個團隊合作的微型前端架構來說，很少有益。我們建議盡快投資設計系統，並在開發設計系統時實作共享方法。