什麼是前端的 MVP？
MVP（Minimum Viable Product）這個詞在產品圈很紅，但在前端架構的語境下，它的意思稍微不一樣。
產品的 MVP 是指「用最少功能驗證市場需求」。而前端的 MVP 設計，是指「一個前端專案從零開始，至少需要哪些基礎架構，才能讓它可維護、可擴展？」
你有沒有接過那種專案 — 一開始為了「快速上線」什麼架構都沒想，三個月後就變成義大利麵 code，改 A 壞 B，沒人敢碰？這就是缺乏 MVP 設計的後果。
我自己的想法是：花個半天到一天把基礎架構想清楚，能讓後續幾個月的開發速度快非常多。這不是 over-engineering，這是基本的投資。
前端 MVP 的核心元素
一個前端專案的最小可行架構，至少需要考慮這幾個層面：
graph TB UI["🖥️ UI Layer<br/>元件設計 / CSS 架構"] STATE["🧠 State Layer<br/>狀態管理"] ROUTE["🗺️ Routing Layer<br/>路由設計"] API["🔌 API Layer<br/>資料串接"] UTIL["🔧 Utils / Helpers<br/>共用工具"] UI --> STATE UI --> ROUTE STATE --> API UTIL --> UI UTIL --> STATE UTIL --> API
1. 元件結構（Component Structure）
這是最基本的。你的元件怎麼分類？怎麼命名？放在哪裡？
一個常見的做法是：
src/
├── components/ # 共用元件（Button, Modal, Input...）
├── pages/ # 頁面級元件（對應路由）
├── layouts/ # 版面元件（Header, Sidebar, Footer）
├── hooks/ # 自訂 hooks（React）或 composables（Vue）
└── features/ # 依功能分的模組（auth, cart, profile）
重點不在於用哪種結構，而是團隊要有共識。最怕的是每個人有自己的分法，三個月後沒人找得到東西。
2. 狀態管理（State Management）
「狀態放哪裡？」這個問題不處理好，後面會很痛苦。
一個簡單的原則：
- 元件內部的狀態：用
useState/ref就好（例如 modal 開關） - 跨元件共享的狀態：需要狀態管理工具（例如使用者登入資訊）
- Server 狀態：用 React Query / SWR 來管，不要自己手動管 loading / error
不需要一開始就上 Redux 或 Pinia。先從最簡單的方案開始，等真的感受到痛點再升級。
3. 路由設計（Routing）
路由是 SPA 的骨架。MVP 階段至少要想好：
- 路由結構（巢狀路由怎麼設計）
- 權限控制（哪些頁面需要登入）
- 404 / Error 頁面
4. CSS 架構
CSS 架構是最容易被忽略、但最容易失控的一塊。
常見的方案有：
- CSS Modules：每個元件一個
.module.css，避免命名衝突 - Tailwind CSS：utility-first，開發速度快，但要習慣它的寫法
- Styled Components / Emotion：CSS-in-JS，跟元件綁在一起
不管選哪個，重點是整個專案只用一種方案。混用不同 CSS 方案會讓維護變成噩夢。
5. API Layer
把 API 呼叫統一管理，而不是散落在各個元件裡：
src/api/
├── client.ts # axios/fetch 封裝，統一處理 baseURL、token、error
├── auth.ts # 認證相關 API
├── user.ts # 使用者相關 API
└── product.ts # 產品相關 API
這樣做的好處是：如果哪天要換 API domain、加 header、改 error handling，只需要改一個地方。
設計原則
關注點分離（Separation of Concerns）
UI 歸 UI、邏輯歸邏輯、資料歸資料。不要在一個元件裡面又 fetch API、又處理 business logic、又搞 CSS animation。拆開來，每個部分各司其職。
慣例優於配置（Convention over Configuration）
團隊內統一好「檔案放哪裡」「怎麼命名」「狀態怎麼管」，大家照做就好。不需要每次都來一場架構辯論。
漸進式增強（Progressive Enhancement）
MVP 的「M」就是 Minimum。先做最基礎的版本，確認能運作，再逐步加上複雜的功能。不要一開始就想把所有東西都做到完美。
常見的 MVP 設計錯誤
我自己也犯過這些錯，所以特別列出來：
1. 過度工程化（Over-engineering） MVP 階段就搞微前端、搞 monorepo、搞超複雜的狀態管理。你的專案目前只有三個頁面，真的不需要。
2. 過早優化（Premature Optimization） 一開始就擔心效能問題，瘋狂做 code splitting、lazy loading、memoization。先讓功能跑起來再說。
3. 沒有統一規範 「反正先趕快做完再說」— 這句話是技術債的起源。花 30 分鐘設定好 ESLint + Prettier + 資料夾結構，能省後面幾十個小時的重構。
4. 忽略錯誤處理 只想 happy path，沒考慮 API 失敗、網路斷線、使用者亂輸入。MVP 不代表不處理 error，至少要有基本的 error boundary 跟 fallback UI。
簡單來說
前端 MVP 設計不是要你把所有東西都做到最好，而是在開始寫 code 之前，先把「最少但必要」的架構決定好。
一個好的 MVP 架構，能讓你在後續需求變動的時候，可以從容地擴展，而不是每次都在「打掉重練」。