前端不再是一整包：微前端初體驗實戰心得

前言

在我還沒入職前，公司原本以 React 作為主要的前端開發框架。隨著專案的需求變化與團隊技術方向的調整，後續新功能與模組都開始改以 Vue 進行開發，因此我踏上了微前端之旅。

由於已經使用 React 開發一段時間了，人力與時程上的限制，React 專案無法立即淘汰，Vue 新功能也需要儘早上線，感覺是公司為了解決這樣的耦合與協作問題，導入了 微前端架構，讓各子系統能夠獨立開發與部署，並實現在單一系統中共存 React 與 Vue 的彈性架構。

這篇文章是我作為使用微前端在開發過程中的觀察與心得整理，若有錯誤之處，還請見諒，畢竟我並未全程參與前期的微前端架構的規劃與建置。

架構分層設計

在微前端架構中，前端應用通常可以分為四層，分層這部分的命名看團隊怎麼去規範，大致分別為：

分類	說明
Host 系統入口／容器	整個應用的入口，負責統整各子系統（System），載入 remote 模組。在 Module Federation 中稱為 Consumer 或 Host。
System 獨立子系統	具備完整功能的子系統，獨立部署，擁有自己的 router、狀態，透過 Module Federation 作為 Remote 提供給 Host 使用。
Module 功能模組	具備邏輯與副作用的功能單元，可能操作 store、呼叫 API，常被多個 System 重複使用。
Component UI 元件	最基礎的 UI 單元，純呈現與樣式，不應有副作用或外部依賴，通常集中在共用 UI Library 中。

Host：系統入口點

• 負責整體 layout、登入流程、統一樣式與外框。
• 為微前端架構的容器，初始化 Module Federation。
• 載入各個子系統（System）並整合畫面。

System：獨立子系統

• 各自為一個完整的功能系統，如會員系統、訂單系統。
• 可獨立開發、獨立部署，擁有自己的 router 與狀態管理。
• 以 exposes remote 的形式被 Host 載入。

Module：功能模組

• 可被多個 System 共用，具備一定的邏輯與副作用（如打 API、處理資料、操作 store）。
• 從外部看起來像 UI component，但職責更重，因此獨立命名為 Module。
• 對 System 而言，Module 就像 SDK，直接使用即可，無需關注其內部實作。

Component：純 UI 元件

• 僅處理 UI 呈現與樣式，無副作用、不涉及業務邏輯。
• 如 Button、Input、Modal 等。
• 集中於共用 UI Library 中，提供給 Module 或 System 使用。

這樣的分層設計可以強化職責分離，提高維護與擴充性以及降低模組之間的耦合。

技術選擇

使用了以下技術組合來實現微前端：

• module-federation
  作為模組間的共享與動態載入機制，讓應用之間能彼此引入模組、共用資源。

• @module-federation/bridge-vue3 與 @module-federation/bridge-react19
  解決 Vue 與 React 間的相容問題，讓兩者的元件能夠互相嵌套與溝通，實現跨框架整合。

• 多應用獨立管理（獨立 repo / CI / 部署）
  每個子系統或是模組（System / Module）都是獨立的 Git 倉庫與部署，能根據需求調整技術、建置流程與版本管理，保持彈性。

微前端的好處

• System / Module 獨立部署，錯誤不影響整體系統
  每個 System 或 Module 都有自己的版本、自己的 CI/CD 流程，彼此之間不會互相干擾，所以當某個 System / Module 掛掉，並不會去影響整體系統的運作，提高容錯能力。

• 多框架共存
  Vue 與 React 可同時並行開發，讓舊有 React 專案持續維護的同時，能用 Vue 推進新需求，降低重構風險與人力成本。

• 漸進式重構
  無需一次性大規模替換 React，能逐步將舊系統拆解成 Vue 子系統，實現逐步將 React 專案轉換成 Vue。

• 共用模組，提升效率與一致性
  將常用邏輯（如：API 操作、表單驗證、圖表呈現）抽離成獨立 Module，可被多個 System 重複使用減少重複實作，提升開發效率與一致性。

微前端的壞處

• 初始載入較慢
  各子系統會載入自己的 JavaScript 與 CSS 資源，初次載入時可能會感受到延遲，尤其是首次切換至尚未使用過的模組時。

• 多開專案，開發成本上升
  在日常開發中，通常需要同時開啟 Host、System，甚至是 Module 等多個專案環境。開發者需理解與跳轉多個專案架構，思緒容易中斷，開發與除錯過程相對繁瑣。

• 狀態管理難以整合
  React 與 Vue 各自有不同的狀態管理方案（Redux、Zustand、Pinia、Vuex 等），若沒有統一標準，容易產生混亂。實務上，通常需要選擇一套作為全局狀態的主導工具。

• Bridge 解決跨框架問題，但寫法冗長
  使用 bridge 將 React 元件包裝成 Vue（或反之）時，需要額外寫 wrapper、props、事件轉換等邏輯，造成開發流程變得繁瑣，尤其在處理雙向綁定或事件回傳時。

• 模組生命週期難以控管
  不同框架有各自的生命週期，像是 Vue 在 setup 階段時 React 模組還沒掛載完成，會導致取不到內容或執行順序錯亂。

• 使用者體驗狀態無法統一控制
  若模組未提供如 disabled、loading、error 等狀態對外暴露，主應用將無法統一處理使用者體驗，容易出現畫面不一致或互動邏輯衝突的情況。

結語

微前端確實在架構轉換的過渡期間，為我們提供了一個務實且彈性的解法，讓團隊能夠在不中斷既有開發的情況下，逐步導入其他技術，降低一次性重構的風險與成本。對於開發者而言也有不少挑戰需要面對，包括跨框架整合的技術複雜度、模組生命週期的不同步，以及多專案開發所帶來的體驗上的落差。

對我個人來說，這是一段非常有價值的學習與實戰經驗。它讓我更清楚認識到，微前端不是萬用解法，而是一種階段性的選擇。是否適合導入到專案裡面是看團隊的目標、規模與共識。技術最終是服務於需求，好的架構不是最先進的，而是最貼合當下狀況的。