為什麼 “大前端” 需要 “微前端”？

引言

我自己經歷了兩個團隊，它們都有著非常相似的業務，其中一個採用了微前端架構，一個沒有採用前端架構，正是因為我親身感受過這兩種不同的架構模式，所以我對這兩種模式有著深切的體會。我想結合我自己的感受，以及我對微前端的了解，來談談我們為什麼需要微前端。

內容比較長，沒時間看的同學可以先收藏起來慢慢看。

什麼是大前端？

大前端指的是前端開發的職責和技術範圍的擴展，不僅僅局限於瀏覽器端開發，涵蓋了整個前端技術體系，強調跨平台開發和統一管理。

技術棧角度：

1. Web 前端：PC 網站、移動 H5 頁面
2. 跨端開發：Hybrid 應用、React Native、Flutter、小程序
3. 桌面端：Electron 等桌面應用
4. 後端相關：Node.js 服務、BFF 層
5. 基礎設施與運維：性能優化、工具鏈、前端監控

開發流程：

大前端不僅負責業務代碼開發，還涉及構建、DevOps、性能優化等環節。例如，客戶端任務可以轉移到構建階段（如SSG），或通過SSR將任務移至伺服器，結合容器技術定制應用環境，實現更高的靈活性。

業務角度：

大前端團隊負責同一C端產品的全業務線開發，儘管團隊內部可按業務劃分小組，每個小組專注特定業務。比如，差旅平台的大前端團隊負責機票、酒店、火車等各項系統的開發，並承擔公共內容（如UI元件庫、請求庫等）的架構管理。

背景

為了方便我們後續討論，假設我們的業務背景是開發一個行程預定APP，包含機票、酒店、火車票等業務，每個業務又包含了列表頁、下單頁、訂單詳情以及售後頁面。首頁是我們各個業務的入口，承擔搜索功能。

通常情況下我們有以下幾種架構可以選擇Architecture

單應用架構 (Single-App Architecture)

最簡單的我們可以將首頁、機票搜索、下單頁、支付、訂單詳情，全部在同一個專案中，那它們的元件在同一個專案中，可以實現共享。如果你採用SPA模式跳轉頁不需要重新刷新頁面，所以用戶看不到白屏，甚至我們可以利用過渡動畫和keepalive，預加載，預請求等技術給用戶流暢的用戶體驗。

場景：

有兩個需求，一個是機票業務，另一個需求是修改火車票業務，明明這兩個需求並不相關，但是我們在一個代碼庫中，合併代碼發布代碼我們勢必要對齊。一個需求回退勢必會導致另一個需求的回退，要麼我們選擇先後順序發布，無論是哪種方式它們之間產生了影響，不同業務的人在同一個代碼庫中操作久而久之會越來越混亂。

這只是一個簡單的案例，真實案例中這種需求成百上千，開發人員和管理團隊都需要很大的精力來分析並且處理這些事物。大大增加了開發人員的溝通成本，也容易讓業務之間相互影響。

上述案例只是為了說明架構的演進，我相信很多人會直接跳到後面的架構而不是真的會去採用單應用架構，如果一個業務相對比較簡單，那麼我們採用上述架構完全沒有問題，在後續業務迭代的時候再新增應用變成多應用架構。

我們這裡的Single-App Architecture 和 SPA 有所區別 SPA指的是單頁應用，強調的是一個應用只有一個頁面，只會加載一次html，後續都是通過js實現虛擬的頁面跳轉，我們這裡的Single-App Architecture 有可能是SPA也有可能是MPA，它們是不同維度的概念需要加以區別。

多應用架構 (Multi-App Architecture)

我們可以把上述應用拆分成多個應用，不僅僅可以按照業務拆分，我們也可以將同一業務拆分成小的子領域，例如預定前和預定後可以拆分成不同的應用。

例如上述的應用我們可以按照以下維度拆分

最後頁面會拆分成

1. 首頁應用 （比較特殊，我們先不討論）
2. 機票列表頁
3. 機票預定頁
4. 酒店列表頁
5. 酒店預定頁
6. 火車列表頁
7. 火車預定頁

我們採用多個單體應用組成一個多應用架構，不同的應用負責不同的業務領域，通過相互跳轉的方式傳遞信息從而串聯這個系統，這樣就不會出現上述不同業務之間的相互影響，不同的業務團隊發布各自的系統即可。

但是這裡有一個頁面是特殊的首頁，首頁中同時包含了三個業務，那麼這個應用應該由誰來維護呢，如果我們仍然採用上述的SPA架構，同樣會面臨多個團隊開發同一應用的困境，問題仍然沒有解決。我們來梳理一下這種模式的優點和

優點

1. 發布更加靈活
2. 不同的領域相互隔離
3. 開發者專注於自己的領域

題外話：強烈建議跳轉通過TS約定好類型，封裝成單獨的方法對外暴露，跳轉的參數問題是最容易出現問題的之一，而且是最常見的增加溝通成本的環節。

公共依賴如何解決？

但是新的問題也就產生了，雖然是獨立的業務，或者同一業務的不同頁面之間，其中難免有一公共的東西，例如：

• 公共的頭部
• 公共的底部
• 工程化代碼
• UI元件庫
• 請求庫
• 環境變量（例如語言），用戶信息
• 和Native交互的AppSdk等

多應用+共享模組

為了解決按照領域劃分的公共依賴問題

一個有經驗的開發者這時候會想到模組化 npm/模組聯邦等，沒錯，在實際工作中很多團隊就是這樣解決的，總結下來有兩種方式引入。

構建時引入

我們可以將一些公用的元件，業務邏輯，底層邏輯封裝成單獨的元件，在使用的時候安裝，這樣我們就實現了代碼的重複利用，讓業務邏輯更清晰，專業的人做專業的事。

渲染時引入

我們可以在引入的時候採用遠程的url引入，或者我們可以採用模組聯邦的方式引入模組，這樣做的好處是，公共模組的更新無需讓業務方再安裝一遍，公共模組的開發者也能更好的控制更新迭代。讓然前提是更新是向下兼容的，對於那些破壞性的更新，應該遵循版本號的約定，需要使用方重新安裝並測試再去使用往往更加穩妥。

這兩種方案各有利弊。

構建時引入：公共庫的版本升級一定要伴隨著使用方（業務方）的重新安裝、測試、發布。

渲染時引入：在沒有破壞更新的情況下，公共庫的開發方發布後，使用方無需重新走發布流程，但是在公共庫的開發者需要考慮更多的兼容性，需要經過充分的測試後發布。

需要注意的是渲染時候引入我們同樣可以使用服務端渲染，在伺服器端預加載模組讓其變成靜態模組，渲染時引入可以採用客戶端渲染也可以採用服務端渲染，兩者並不衝突。

我們拿一個真實案例來看看，對於上述的首頁，機票，酒店，火車票的業務方你會採用哪種模式呢

構建時引入還是渲染時引入呢？

上述的架構很好的拆分了業務，也很好的處理了業務公共模組，已經能夠滿足大部分業務場景，但是

仍然有不足之處，甚至可以說是最大的瓶頸。

跨應用上下文斷裂（Context Fragmentation）

在多應用架構中，業務被拆分成多個獨立的應用。當用戶從一個應用跳轉到另一個應用時，雖然可以通過 URL 參數、Storage 等方式傳遞部分信息，但卻缺乏一個真正意義上的 頁面級上下文。

所謂“頁面級上下文”，指的是：

• 用戶打開頁面時存入變量；
• 頁面關閉時變量隨之銷毀；
• 上下文僅對當前頁面有效，不受其他頁面影響。

然而，瀏覽器原生能力並不能滿足這一點：

• sessionStorage 生命週期依賴於瀏覽器窗口，而非單個 tab；
• localStorage 則是全局共享，更不適合做單鏈路的上下文管理。

典型場景：渠道權益校驗

舉一個真實的業務需求（我在兩家公司都遇到過類似問題）：

只有通過特定渠道鏈接進入的用戶，在下單時才會享有某項權益。

在這種場景下，常見的實現方式有兩種：

1. URL 參數傳遞

   • 必須將渠道 code 等信息從入口頁面一路傳遞到下單頁面；
   • 鏈路長、依賴多，極易遺漏。

2. Storage 存儲

   • sessionStorage/localStorage 雖能跨頁面共享，但無法限制在單鏈路內；
   • 無法在 tab 關閉時銷毀，容易污染或錯誤復用。

為了實現這樣的需求，我們動用了近5個團隊改近了近百處跳轉，任何一個環節遺漏，都会導致整個業務鏈路中斷，我們團隊相對較好是因為我們團隊內部使用了微前端，跳轉對於我們是可控的。

為什麼需要頁面級全局上下文

一個真正的 頁面級全局上下文，不僅能解決上述鏈路問題，還能帶來額外價值：

1. 全局開關

   • 比如某個功能需要所有產線統一遵循。

2. 用戶信息管理

   • 用戶語言、偏好設置等信息無需重複傳遞。

3. 頁面通用元素

   • 例如 Header、Footer，避免重複接入和維護。

雖然也有替代方案，但這些方案往往繁瑣、冗餘，遠不如原生的上下文模型簡潔高效。

多應用架構的弊端總結

在缺乏頁面級全局上下文的前提下，多應用架構存在以下核心弊端：

1. 斷裂的上下文

   • 應用間無法自然共享上下文，導致信息傳遞冗餘且容易出錯。

2. 用戶體驗的割裂

   • 頁面跳轉出現白屏、加載延遲；
   • 返回操作需要重新刷新頁面；
   • 與原生 App 的流暢體驗差距顯著。

3. 公共庫的維護與升級成本高

   • 系統級邏輯（監控、埋點、統計）需要每個應用單獨接入；
   • 公共依賴（如請求庫）分散在各個應用，升級需要逐一改造；
   • 關注點沒有真正分離，造成了巨大的冗餘和協作成本。

案例二：請求庫的升級代價

以請求庫升級為例：

某次網關改造要求將自建請求庫替換為集團共建方案。由於請求庫分散在各個應用角落，升級工作量巨大：

• 需要在所有應用中重新安裝依賴、修改調用方式、適配新庫；
• 通過統計数据显示，僅前端側就耗費了一名工程師 一年半的全部時間。

這並非個體執行力問題，而是 架構層面缺乏統一治理能力：

• 沒有明確規劃哪些是公共能力、哪些由業務方負責；
• 即便有規範，長期迭代中也容易走樣；
• 團隊更替、新方案出現時，容易偏離原有約定。

強制依賴“人來遵守”往往效果有限；

如果有更強的 架構機制 來分離公共與業務邏輯，問題會更容易解決。

答案：基座式微前端

想要解決上述問題：

1. 上下文斷裂
2. 用戶體驗割裂
3. 讓業務團隊專注於業務；
4. 公共 package 可以靈活迭代；
5. 架構策略能夠強有力地執行；

答案就是 —— 基座式微前端架構。

微前端的思想通過在運行時整合多個應用，提供統一的上下文與公共依賴治理機制，天然解決了多應用架構的割裂問題。

為什麼是基座式微前端？

需要特別說明的是，微前端的概念本身非常廣泛：

前端應用可以被拆分為多個子應用，再通過 構建時集成、服務端拼裝 或 瀏覽器運行時加載 等不同方式組合。無論是哪種形式，都可以被稱為“微前端”。例如 Module Federation、Bit 等方案，本質上都屬於微前端的範疇。

但是，這些方案並不一定能解決我們前面提到的關鍵問題：

• 上下文斷裂
• 用戶體驗割裂
• 公共依賴升級困難

要真正解決這些問題，需要的是 —— 基座式微前端（Host-based Micro Frontend）。

什麼是基座式微前端

基座式微前端，也可以叫做基座-子應用架構：

• 由一個 基座應用（Host App） 負責全局上下文、路由和依賴管理；
• 子應用（Sub Apps）在基座之上運行，並與基座共享上下文（如用戶信息、語言、功能開關等）；
• 頁面跳轉無白屏，體驗流暢一致；
• 公共庫和系統級邏輯集中治理，避免重複接入和難以升級的問題。

基座式微前端的優勢

在討論這些優勢之前，需要明確一點：只有在合理且有效地使用基座式微前端架構的前提下，才能真正發揮其優勢。舉個例子，即便採用了微前端架構，如果各團隊仍然各自實現登錄邏輯，頁面跳轉方式與傳統 MPA 相同，那麼微前端帶來的好處幾乎無法體現。換句話說，合理使用、並由專門團隊維護基座應用，是發揮微前端優勢的前提。

1. 職責分離

這裡的職責分離更多強調縱向分離，即基礎能力開發與業務開發之間的分工，而非不同業務模組之間的分工。

• 每個子應用所需的通用能力，無需業務團隊重複實現，可由基座應用統一提供。例如：
  • 錯誤監控
  • 用戶行為記錄
  • 權限控制
  • 全局 UI 主題管理
  • 子應用間通信
  • 應用級灰度發布
  • 應用出錯時的回退處理

這種縱向職責分離可以讓業務團隊專注於核心業務開發，提高開發效率並降低重複勞動。

2. 版本共存

在開發新功能時，我們通常會進行灰度發布，但很多情況下這只是簡單的開關和兼容舊版本，而不是嚴格意義上的灰度。

• 微前端架構允許同一應用的多個版本共存。基座應用在載入子應用時可以決定使用哪個版本，從而實現真正的灰度發布和版本回退。
• 舉例來說，如果某周發布的新版本包含對酒店、機票模組的重大修改，想回退到上個版本，只需將應用註冊表切換回舊版本即可。
• 當然，這裡的回退僅指前端代碼層面；如果涉及配置變更，也需進行相應回退。如果其他內容也實現了版本化處理，版本回退甚至可以實現自動化，無需人工干預。

3. 解決多環境問題

當不同應用處於不同測試環境時，統一跳轉到同一測試環境往往非常麻煩，溝通成本很高。

• 微前端架構下，只需將開發中的應用指向對應環境，其他應用保持穩定版本即可，極大簡化了多環境管理。

4. 跨應用用戶體驗提升

1. 及時響應：頁面切換可快速完成，同時支持友好過渡動畫，避免傳統點擊跳轉的突兀感。
2. Keep-Alive：支持頁面回退時保持上一頁的 DOM 狀態，提高用戶體驗和操作連續性。

5. 跨應用性能優化（不是微前端獨有，但是更容易實施）

微前端架構在性能上也有明顯優勢：

1. 請求復用：避免重複請求，提高加載效率。
2. 預加載：提前加載子應用資源，縮短等待時間。
3. 預請求：根據用戶操作預判加載下一步可能需要的資源，提高響應速度。

6. 全局會話管理

基座式微前端架構支持全局會話機制：

• 無論應用如何跳轉，只需提供統一的全局會話存儲變量，用戶狀態即可持續存在。
• 例如多模組的修改操作，不再因跳轉而丟失用戶會話信息。

總結來說，基座式微前端在職責分離、版本管理、多環境支持、用戶體驗、性能優化和全局會話管理等方面都具有顯著優勢，但前提是必須合理使用，並由專門團隊維護基座應用。

微前端常用的框架和技術棧

客戶端集成 — single-spa

single-spa 是一個 JavaScript 微前端框架，用於將多個單頁面應用（SPA）聚合為一個整體應用。通過使用 single-spa 進行前端架構設計，可以帶來以下好處：

• 在同一頁面中集成多個前端框架，而無需刷新頁面（如 React、AngularJS、Angular、Ember 等）。
• 支持每個單頁面應用的獨立部署。
• 新功能可以使用新框架，而舊的應用無需重寫即可與之共存。

single-spa 的基座應用非常輕量，甚至無需使用 React。子應用只需導出符合約定的生命週期方法：bootstrap、mount、unmount。

不過，single-spa 也存在一定的局限性：

1. 子應用以 JavaScript 形式存在，只能在客戶端加載並渲染。
2. 不提供沙箱機制。如果多個子應用共存，需要各自負責清理副作用，否則可能產生衝突。

帶沙箱的客戶端集成 — qiankun / wujie / microApp

與 single-spa 類似，這類框架同樣通過在客戶端組裝多個子應用來實現微前端。

不同的是，它們引入了沙箱機制，利用瀏覽器特性（如 Proxy、iframe 或快照恢復）對每個子應用的全局變量和副作用進行隔離，從而保證安全邊界，避免子應用之間的相互影響。

這使得它們更適合橫向拆分的複雜頁面場景，能夠在保證獨立性的同時，提供更穩定的運行環境。

Module Federation (MF)

Module Federation 是一種 JavaScript 應用的分治架構模式（類似於後端的微服務）。它允許多個應用（或微前端）之間共享代碼和資源，從而支持應用的拆分與按需加載。

需要注意的是，Module Federation 解決的核心問題是“如何在應用之間加載和共享模組”。換句話說，採用 Module Federation 並不一定就是微前端架構，而實現微前端也不必依賴 Module Federation。

模組聯邦和上述的方案完全不衝突，single-spa/qiankun/wujie/microApp 解決的是應用的加載卸載，Module Federation 解決的更多是模組導出與加載，只不過你也可以將應用看做一個模組，利用 Module Federation 導出給 Host 應用使用，你也可以在使用其他微前端框架的情況下在某個子應用中使用 Module Federation 導入元件，它們是可以共存的。

接下來我們重點討論一下帶沙箱的客戶端集成 — qiankun / wujie / microApp，說到微前端大部分人都會想到這幾個方案。

qiankun / wujie / microApp 這些微前端框架看上去已經很成熟了，但是在C端使用這些框架的卻很少，而在大部分文章中都會說微前端不是銀彈，我想更多的是因為這些框架的缺點有關，而不是微前端這種理念，正是因為這些缺點讓很多人在落地微前端的時候望而卻步。

客戶端集成微前端的缺點

客戶端渲染依賴強

• 子應用通常以 JavaScript bundle 的形式存在，只能在瀏覽器端加載和渲染。
• 對於那些本來支持服務端渲染或者流式渲染的子應用，基座應用也需要等 html 加載後解析，最終的呈現仍然是客戶端渲染而不是真正的服務端渲染，很多框架所說的支持服務端渲染，準確的來說應該是支持將子應用的服務端渲染在基座應用中以客戶端渲染的方式嵌入，而不是真正的在服務端渲染。

全局狀態與副作用管理複雜

• 多個子應用共存時，全局變量、事件綁定、定時器等副作用容易互相影響。
• 如果框架不提供沙箱（如原生 single-spa），每個子應用需要自行處理副作用的清理，否則可能導致衝突或內存洩漏。
• 即便是有沙箱仍然有逃離沙箱的方法。

額外的性能開銷

• 沙箱離不开 with 函數，proxy，甚至客戶端對 js/css 的重寫，增加了額外的性能開銷，with 打破了靜態作用域，使得引擎無法進行優化，函數調用、屬性訪問和循環性能都會下降。

調試變得複雜

子應用不再是一個完整的系統，在開發時需要啟動多個應用，如果在落地時不考慮這些因素，往往會導致開發者的效率變低，我想這是很多開發者討厭微前端的原因之一。

即便微前端有這麼多優點，但是在落地具體框架中仍然存在這麼多問題，這些缺點絲毫不影響它的優點，我想這並不是微前端這種理念的問題，只能說明目前的框架仍然存在很多問題需要解決，甚至很多方面我們需要重新思考。

更好的微前端

參考 Cloudflare Workers 和微前端：為彼此而生 這篇文章，我們可以獲得一些啟發。實際上，這種方案的核心思想完全可以脫離 Cloudflare Worker 獨立存在。結合我們的痛點和實踐經驗，我們可以構建出一個更加高效和安全的微前端解決方案。

構建時沙箱

現有的微前端沙箱機制大多是在客戶端實現的，這帶來了額外的運行時開銷，並且難以及早發現潛在問題。更理想的方案應該在構建階段就完成沙箱處理：

• 子應用隔離：在構建時就能確保每個子應用的代碼符合規範，同時在開發階段就能發現試圖“逃離沙箱”的寫法。
• CSS 沙箱：通過在構建階段解決樣式衝突，可以避免客戶端額外的樣式處理，從而提升性能。
• 自動卸載邏輯：我們可以在構建時將子應用的卸載代碼集成進去，使其在宿主應用中表現得就像一個普通元件，無需宿主額外處理。

在這裡不得不提一下 bit.dev。bit.dev 支持將應用的工程化代碼（例如腳手架、webpack 配置等）也作為一個元件進行管理。假如修改了工程化元件，所有依賴這些元件的專案都可以觸發重新構建。這種思想對於微前端落地非常關鍵，因為構建本身直接影響代碼的最終呈現。如果工程化代碼無法高效迭代，微前端的可維護性和穩定性都會受到嚴重影響。

支持流式渲染（Stream SSR）

為了提升用戶體驗，我們希望微前端能與服務端渲染（SSR）兼容，甚至支持流式 SSR（Stream SSR）。很多人認為微前端和 SSR 衝突，但實際上並非如此：

• 如果採用構建時沙箱，子應用可以在宿主應用的服務端渲染階段就開始請求數據。
• 子應用可以在宿主應用渲染 HTML 時同步返回部分內容，實現流式渲染。
• 對用戶而言，這種方式與傳統 SSR 應用體驗無異，同時避免了客戶端額外的加載和渲染開銷。

換句話說，微前端並不必然犧牲 SSR 或流式渲染性能，通過合理的構建時策略，子應用可以像普通 SSR 組件一樣參與服務端渲染，同時保持隔離和獨立性。

等到我們擁有這樣的微前端架構再來回答，微前端是不是銀彈這句話也不遲，我相信 AI 也會加速這類框架的誕生。

構建更高效、靈活的前端開發平台

儘管“更好的微前端”形態尚未完全到來，但通過合理使用微前端，我們依然能夠構建一個可插拔、可演進的前端開發平台，帶來諸多優勢：

1. 提升迭代效率

   • 公共庫的開發者能夠更高效地升級和維護基礎庫，業務開發者則能專注於領域業務，成為真正的業務專家，減少對公共庫的額外關注。

2. 增強復用能力

   • 代碼復用：通用邏輯沉澱並復用，避免重複開發。
   • 運行時復用：通過微前端，許多原本需要單獨請求的業務操作只需一次請求，減少性能開銷。

3. 優化用戶體驗

   • 微前端實現跨應用跳轉無需刷新頁面，且能保持前一个應用的狀態，帶來更接近原生應用的流暢體驗。

4. 減少架構限制

   • 微前端打破了傳統架構的上下文隔離限制，原本因為架構限制而無法實現的需求，如今能通過微前端靈活地解決，開發者無需依賴高人力成本的替代方案。

5. 規範化落地

   • 基座應用不僅承擔渲染任務，還能負責監控和規範實施，幫助發現和阻止不規範的 API 調用，如未加業務前綴的存儲操作、不合規的跳轉鏈接等。

6. 強化混合應用能力

   • 在 Hybrid 場景下，將負責與客戶端交互的 App SDK 內置到基座。基座對 WebApp 提供穩定的橋接 API，SDK 升級只需更新基座，業務層幾乎零感知，極大地減少了升級成本並提高了版本控制的靈活性。

大前端通常服務一個大的產品，而這個大的產品既需要分而治之，又需要代碼公用，還需要高效迭代。微前端的架構正好給我們提供了這樣一個可能。

我在做百變AI助手時，就使用了上述基座微前端的架構，能夠做到 AI 生成的代碼在各個中平台運行，因為適配宿主環境的能力和子應用調用的能力都是通過基座應用實現的。

有了基座應用的橋接，我無須擔心後續宿主環境的調整需要子應用重新生成，即便需要重新生成，我也可以通過基座應用監控那些應用需要重新生成。

如果這篇文章對你有幫助，記得關注，後續我還會持續分享更多做專案的真實體驗。

原文出處：https://juejin.cn/post/7551624075611013171