資深前端面試常不會給你一個明確 API 題，而是問：
如果要設計一個多人使用、資料量很大的管理 Dashboard，你會怎麼規劃？
這類題目沒有唯一答案。面試官想看的是你能不能先澄清需求，再做有理由的取捨。
第一步：先問需求
不要一拿到題目就開始畫 component tree。
先確認：
- 主要使用者是誰？
- 核心操作是讀取、編輯還是即時監控？
- 資料量與更新頻率？
- 是否需要 SEO？
- 是否有角色權限？
- 是否要支援離線、手機或多語系？
- 成功指標是載入速度、操作效率還是資料即時性？
需求會決定技術選擇。
元件怎麼拆？
可以從責任邊界切分：
DashboardPage
├── FilterBar
├── SummaryMetrics
├── DataTable
│ ├── TableHeader
│ ├── VirtualizedRows
│ └── Pagination
└── DetailDrawer拆分原則：
- 元件有清楚責任
- 重用是實際需求，不為抽象而抽象
- 資料取得和純 UI 可以適度分離
- 避免所有 state 堆在最上層，也避免過度分散
狀態怎麼分類？
| State | 例子 | 建議位置 |
|---|---|---|
| URL state | filter、sort、page | query string |
| Server state | table data、cache | TanStack Query / data layer |
| Local UI state | drawer、hover、input draft | component |
| Global client state | user preference、跨頁工作流程 | Zustand / Redux 等 |
分類後再選工具，不要把所有東西放進同一個 global store。
API 與資料層
大型列表需要考慮：
- server-side pagination / cursor
- filter 和 sort 由後端處理
- request cancellation
- cache key 設計
- stale time / refetch
- optimistic update
- error normalization
API response 最好有穩定 contract：
type PageResult<T> = {
items: T[];
nextCursor: string | null;
total?: number;
};效能怎麼規劃？
不要只回答 memo。
先從較大層級處理：
- 不要一次下載全部資料
- 列表使用 virtualization
- route / component code splitting
- 圖片 lazy loading
- 避免重複 request
- 最後才針對昂貴計算與 re-render memoize
並定義可量測目標，例如 LCP、INP、列表操作 latency。
錯誤與權限
至少要考慮：
- loading / empty / partial error
- retry 和 fallback
- API timeout
- 權限過期
- 403 與 404 的 UI
- mutation 失敗 rollback
前端隱藏按鈕不是安全權限，後端仍必須驗證每個操作。
Design System 和共用元件
大型專案需要一致的：
- Button、Input、Dialog、Table
- color / spacing / typography tokens
- accessibility behavior
- loading / error pattern
- 文件與範例
但不要太早把所有業務元件塞進 design system。Design system 應該放穩定、跨產品可重用的視覺與互動 primitive。
測試與可觀測性
系統設計回答如果能補這一段，完整度會高很多：
- unit test：資料轉換、權限規則
- integration test：filter、table、API 狀態
- E2E：登入、查詢、編輯核心流程
- error tracking：未捕獲錯誤、source map
- Web Vitals：正式環境效能
- analytics：核心操作成功率
常見追問
Monorepo 什麼時候值得用？
多個 App 共享 design system、types、tooling，且需要原子化修改時可以考慮。只有一個小 App 時不必為了流行導入。
Micro-frontend 什麼時候需要？
主要解決大型組織獨立部署和 ownership，不是一般元件重用方案。它會增加 runtime 整合、版本、樣式與監控複雜度。
怎麼避免架構過度設計？
先解決已知需求，替高機率變動處保留邊界，用數據和實際重複再抽象，不為假想需求增加層次。
面試回答模板
我會先釐清使用者、資料量、更新頻率、權限和效能目標，再設計元件與資料流。狀態會區分 URL、server、local UI 和 global client state；大量列表採 server-side pagination 與 virtualization；資料層處理 cache、cancellation、retry 和 mutation。最後補上 accessibility、測試、錯誤監控和 Web Vitals，並說明哪些地方先保持簡單，避免過度設計。