Vue 專案的複雜度通常不是從元件數量開始失控，而是從業務邏輯散落在頁面、元件和 store 之間開始失控。2026 年的 Vue 團隊更需要關注組合式架構：哪些邏輯應該抽成 Composable，哪些狀態應該留在元件內，哪些能力應該沉澱為業務模組。
Composable 不是萬能抽象
一個常見誤區是把所有邏輯都抽成 useXxx。這樣短期看起來複用率變高，長期卻容易出現隱式依賴、生命週期混亂和測試困難。更穩妥的做法是把 Composable 分成三個明確層級：
第一層：基礎能力 Composable（Infrastructure）
這一層隻處理穩定的技術問題，與業務無關。典型例子：
useRequest：封裝請求取消、重試、快取和競態處理useDebounce/useThrottle：輸入防抖和節流useIntersectionObserver：元素可見性監聽useEventListener：事件繫結和自動清理useMediaQuery：響應式斷點檢測
基礎能力層的特徵是高複用、零業務耦合、單向依賴。它們不引用任何業務型別或領域邏輯，可以在不同專案間直接移植。
第二層：業務流程 Composable（Domain）
這一層承載明確的領域規則，是對業務邏輯的結構化表達。典型例子：
useProductSearch：封裝商品搜尋的查詢、篩選、排序和分頁邏輯useOrderFlow：封裝下單流程的狀態機（購物車→地址→支付→確認）usePermission：封裝當前使用者的權限校驗邏輯useFormValidation：封裝特定業務表單的校驗規則
領域層的特徵是明確的業務邊界、可獨立測試、依賴方向單向指向基礎層。這一層的 Composable 通常包含業務特有的型別定義和常數。
第三層：頁面適配 Composable（Adapter）
這一層負責把業務流程轉換成當前頁面或元件需要的狀態形態。典型例子：
useProductListPage：組合useProductSearch+usePagination+ 路由參數useDashboardData：聚合多個資料來源的 loading/error/data 狀態useUserProfile：組合使用者資訊、權限和編輯狀態
適配層的特徵是生命週期繫結到具體頁面、組合多個領域 Composable、暴露視圖專用狀態。它們通常不會被其他頁面複用。
三層之間保持單向依賴：適配層 → 領域層 → 基礎層。這個約束讓專案規模變大後仍然容易追蹤依賴方向。
狀態邊界要提前設計
Vue 的響應式系統足夠靈活，但靈活不等於可以隨處共享狀態。2026 年的最佳實踐是將狀態按作用域分為四個等級：
L1：元件內部狀態（Component State） 適用於表單輸入、彈窗開關、當前 tab、局部 loading 等。特點是生命週期短、依賴範圍明確。使用 ref 或 reactive，不需要也不應該被外部訪問。
L2：共享元件狀態（Shared Component State） 適用於父子元件或兄弟元件之間的狀態傳遞。首選方案是 defineProps + defineEmits，其次是 provide/inject。避免一上來就用全域 store。
L3：模組級狀態（Module State） 適用於一個業務模組內部多個頁面共享的狀態。典型的實現是建立一個模組級別的 Composable，內部使用 ref，通過 provide/inject 或模組單例暴露。隻有當多個業務入口都依賴同一份事實來源時，才需要進入這個層級。
L4：全域狀態（Global State） 適用於跨模組的共享狀態，如使用者資訊、全域設定、主題設定。使用 Pinia store，但要嚴格控製數量——一個健康的中大型專案，全域 store 的數量通常不超過 5 個。
關鍵原則：狀態能留在元件內的就不要上升，能模組化的就不要全域化。 每次提升狀態的作用域，都意味著更多的耦合和更複雜的測試。
副作用管理：effect 不是萬能的
Vue 的 watch 和 watchEffect 是強大的工具，但也很容易被濫用。2026 年比較成熟的實踐是：
- watch 用於響應式同步：當 A 變化時更新 B（如路由參數變化時重新請求資料）
- watchEffect 用於除錯和簡單同步：不適合承載複雜業務邏輯
- 業務副作用放在 Composable 的方法裡：顯式呼叫比隱式觸發更容易追蹤和測試
一個實用的判斷標準：如果 watch 的回撥超過 10 行，或者包含了非同步操作和條件分支，那就應該考慮把它重構為一個顯式的 Composable 方法。
測試策略
組合式架構最大的工程收益之一是可測試性的大幅提升。推薦的測試金字塔：
- 單元測試（70%）：針對領域 Composable 的純邏輯測試。因為脫離了元件上下文，可以直接用
@vue/test-utils或單純呼叫 Composable 函式來驗證。這是投入產出比最高的測試。 - 整合測試（20%）：驗證多個 Composable 組合後的行為，以及它們與 Pinia store 的互動。
- 元件測試（10%）：隻覆蓋關鍵互動路徑，不需要為每個元件都寫測試。
程式碼審查時重點關注四個維度：依賴方向是否正確（單向）、狀態歸屬是否合理（四層模型）、副作用入口是否顯式、Composable 的輸入輸出是否明確。
遷移策略：從混亂到有序
如果你的 Vue 專案已經積累了大量混亂的 mixin、過度使用的 store 和散落的業務邏輯，不要試圖一次性重構。更務實的遷移路徑是：
- 先抽基礎層：把純技術工具函式抽取為基礎 Composable，這是風險最低的一步
- 再梳理領域層：每次修改一個業務模組時，順手把相關邏輯封裝為領域 Composable
- 最後整合適配層：在新頁面中使用適配層模式，老頁面逐步遷移
- 每個階段都寫測試：測試是重構的安全網，沒有測試不要做大規模抽象
小結
Vue 2026 的核心競爭力不隻是語法簡潔，而是能否把複雜業務拆成穩定、可測試、可演進的組合單元。三層 Composable 架構（基礎→領域→適配）加上四級狀態模型（元件→共享→模組→全域），為大型 Vue 專案提供了清晰的治理框架。關鍵在於：Composable 服務於業務邊界，而不是成為新的全域工具箱。