魯斯前端布魯斯前端

文章中英模式

布魯斯前端React面試題目 - 如何選擇狀態管理方案

深入解析React狀態管理方案的選擇策略，包括useState、useContext、Redux、Zustand等多種方案的比較與最佳實踐，幫助你根據專案需求選擇合適的狀態管理工具。

影片縮圖

懶得看文章？那就來看影片吧

什麼是狀態管理？為什麼需要不同的方案？

狀態管理是指如何組織、存儲和管理應用程序中的數據。在React應用中，UI是狀態的函數：UI = f(state)。隨著應用規模擴大，狀態管理的複雜度也隨之增加。

不同規模和複雜度的應用需要不同的狀態管理解決方案，主要需要考慮以下因素：

  • 1. 狀態的範圍 - 局部狀態vs全局共享狀態vs原子化狀態
  • 2. 團隊規模 - 小團隊vs大團隊協作
  • 3. 應用複雜度 - 簡單表單vs複雜狀態管理

主流狀態管理方案比較

按狀態範圍分類

類型方案適用場景
局部狀態useState表單輸入控制、切換開關狀態、計數器
useReducer購物車商品管理、多步驟表單、遊戲狀態
共享狀態Context API主題切換、用戶認證狀態、多語言設置
Zustand電商網站購物車、待辦事項應用、簡單的數據儀表板
大型應用Redux企業級管理系統、社交媒體平台、複雜的電商網站
原子化Jotai/Recoil文檔編輯器、繪圖應用、需要細粒度更新的複雜UI

按團隊規模分類

團隊規模推薦方案原因
小團隊/個人項目useState + useContext簡單直觀，快速開發，無需額外依賴
Zustand輕量級，API簡潔，學習成本低
Jotai原子化狀態管理，靈活且易於使用
中大型團隊Redux Toolkit規範化的狀態管理，豐富的中間件，強大的開發工具，適合團隊協作

狀態管理方案簡易權衡

開始選擇狀態管理方案

狀態只在單個組件中使用？

是

使用 useState / useReducer

否（需要共享狀態）

是大型複雜應用？

是

考慮 Redux

否（原子化狀態or全局共享狀態）

使用 Context API / Zustand / Jotai

狀態管理方案複雜度與功能對比

複雜度高
複雜度低
功能簡單
功能強大
useState
useReducer
Context API
Zustand
Jotai/Recoil
Redux

狀態管理方案選擇簡表

useState: 簡單組件狀態
useReducer: 複雜組件狀態
Context: 小型應用共享狀態
Zustand: 中型應用狀態管理
Jotai/Recoil: 原子化狀態管理
Redux: 大型複雜應用

React內建狀態管理方案詳解

1. useState - 元件局部狀態

最簡單的狀態管理方式，用於存儲和更新元件內的局部狀態。

// 使用 useState 管理簡單狀態
import { useState } from 'react';

function Counter() {
  // 宣告一個計數器狀態
  const [count, setCount] = useState(0);
  
  return (
    <div>
      <p>目前計數: {count}</p>
      <button onClick={() => setCount(count + 1)}>
        增加
      </button>
    </div>
  );
}

最佳使用場景：

  • 1. 內部狀態管理 - UI元件的內部狀態
  • 2. 複雜表單狀態 - 表單驗證、錯誤處理
  • 3. 全局狀態 - 應用級別的共享狀態

提示： 當多個useState變量有邏輯關聯時，考慮使用useReducer來簡化狀態管理。

2. useReducer - 複雜局部狀態

當元件狀態邏輯較複雜時，useReducer提供更結構化的狀態管理方式。它基於Redux的思想，但作用範圍限於元件內部。

import { useReducer } from 'react';

// 定義reducer函數
function counterReducer(state, action) {
  switch (action.type) {
    case 'increment':
      return { count: state.count + 1 };
    case 'decrement':
      return { count: state.count - 1 };
    case 'reset':
      return { count: 0 };
    default:
      throw new Error();
  }
}

function Counter() {
  // 使用reducer初始化狀態和dispatch函數
  const [state, dispatch] = useReducer(counterReducer, { count: 0 });
  
  return (
    <div>
      <p>目前計數: {state.count}</p>
      <button onClick={() => dispatch({ type: 'increment' })}>增加</button>
      <button onClick={() => dispatch({ type: 'decrement' })}>減少</button>
      <button onClick={() => dispatch({ type: 'reset' })}>重置</button>
    </div>
  );
}

最佳使用場景：

  • 1. 複雜表單狀態管理
  • 2. 多個相關狀態變量需要同步更新
  • 3. 狀態變更邏輯複雜的元件
  • 4. 需要集中管理狀態轉換邏輯

3. Context API - 跨元件共享狀態

Context API用於在不同層級的元件間共享數據，避免'props drilling'問題。它非常適合於主題、用戶認證等全局信息的共享。

Context API 工作原理

ThemeProvider

存儲theme狀態

Context.Provider

theme: 'dark'

toggleTheme()

Header

不使用Context

Content

不使用Context

Footer

不使用Context

ThemeButton

useContext

⚠️ Context變化時重渲染

Context值變化時重渲染的組件

不受Context變化影響的組件

⚠️ 性能注意事項

Context值變化會導致所有消費該Context的元件重新渲染，不適合頻繁變化的數據。

1. Parent 每次 count 變動時會重新 render

2. ChildA 是 Parent 的直接子元件

3. 所以 即使沒用 context，還是被重新「呼叫」渲染函數

優化技巧：

  • 將狀態拆分為多個Context，減少不必要的重渲染
  • 結合React.memo防止不必要的重渲染
  • 使用useMemo緩存Context值，避免不必要的Provider重渲染
const CounterContext = createContext();

function Parent() {
  const [count, setCount] = useState(0);

  return (
    <CounterContext.Provider value={{ count, setCount }}>
      <ChildA />   
      <ChildB />   
    </CounterContext.Provider>
  );
}

function ChildA() {
  console.log('ChildA render');
  return <p>Hello</p>;
}

function ChildB() {
  const { count } = useContext(CounterContext);
  console.log('ChildB render');
  return <p>Count: {count}</p>;
}

// ------------------------------
const ChildA = React.memo(() => {
  console.log('ChildA render');
  return <p>Hello</p>;
});

// ------------------------------
const ThemeContext = createContext();
const UserContext = createContext();

function App() {
  return (
    <ThemeContext.Provider value={{ theme: 'dark' }}>
      <UserContext.Provider value={{ user: 'John' }}>
        <Main />
      </UserContext.Provider>
    </ThemeContext.Provider>
  );
}

最佳使用場景：

  • 1. 應用主題設置
  • 2. 用戶認證信息
  • 3. 語言/國際化配置
  • 4. 中小型應用的全局狀態

注意： Context不適合頻繁變化的數據，因為Context值變化會導致所有消費該Context的元件重新渲染。可以結合useMemo、memo等優化性能。

第三方狀態管理庫詳解

1. Redux - 成熟的集中狀態管理

Redux是React生態系統中最成熟的狀態管理庫，基於單一數據源和不可變數據的原則，使狀態變更可預測和可追蹤。

Redux 工作流程簡圖

UI

→

Action（狀態變更）

↓

Store（全局共享狀態）

←

Reducer（狀態變更邏輯）

單向數據流: UI → Action → Reducer → Store → UI

// 創建slice（Redux Toolkit）
import { createSlice, configureStore } from '@reduxjs/toolkit';

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    increment: state => {
      state.value += 1;
    },
    decrement: state => {
      state.value -= 1;
    }
  }
});

// 導出actions
export const { increment, decrement } = counterSlice.actions;

// 配置store
const store = configureStore({
  reducer: {
    counter: counterSlice.reducer
  }
});

// 在React元件中使用
import { useDispatch, useSelector } from 'react-redux';
import { increment, decrement } from './counterSlice';

function Counter() {
  const count = useSelector(state => state.counter.value);
  const dispatch = useDispatch();
  
  return (
    <div>
      <p>計數: {count}</p>
      <button onClick={() => dispatch(increment())}>增加</button>
      <button onClick={() => dispatch(decrement())}>減少</button>
    </div>
  );
}

優勢：

  • 1. 狀態可預測性高，便於調試
  • 2. 強大的開發工具支持時間旅行調試
  • 3. 中間件系統擴展功能（異步操作等）
  • 4. 成熟的生態系統和最佳實踐

適用場景：

  • 1. 大型電商平台（如蝦皮、PChome）需管理商品、購物車、用戶、訂單等複雜狀態
  • 2. 企業管理系統（如ERP、CRM系統）處理大量表單和數據流
  • 3. 社交媒體應用（如Facebook、Instagram克隆）管理用戶互動、通知和內容流
  • 4. 金融交易平台需要嚴格的狀態追蹤和審計功能

2. Zustand - 簡潔易用的狀態管理

Zustand是一個小巧且易於上手的狀態管理庫，提供了類似Redux的功能，但有更簡潔的API和更少的模板代碼。

Zustand 工作原理

Zustand Store
單一狀態源

state

{ count: 0 }

actions

increment()

decrement()

Component A

useStore()

只訂閱 count

Component B

useStore()

只訂閱 increment

Component C

useStore()

訂閱整個 store

中央存儲所有狀態和操作

元件可以選擇性訂閱需要的狀態，只有訂閱的狀態變化時才會重新渲染

無需 Provider 包裹，直接訪問 store

Zustand的優點：

  • 1. API簡潔，幾乎無模板代碼
  • 2. 包體積小（約3KB）
  • 3. 不需要Provider包裹
  • 4. 基於hooks，與React集成良好
  • 5. 支持選擇性訂閱，性能優化內建

適用場景：

  • 1. 個人部落格或作品集網站，需要簡單全局狀態但不想引入Redux的複雜性
  • 2. 中小型電商網站（如小型品牌官網）管理購物車和用戶偏好
  • 3. 專案管理工具（如Trello克隆）管理看板和任務狀態
  • 4. 新創公司的MVP產品，需要快速開發並保持代碼簡潔

3. Jotai/Recoil - 原子化狀態管理

Jotai和Recoil提供了原子化的狀態管理方式，將狀態分解為小的、獨立的原子單元，可以組合和派生，適合注重性能的應用。

原子化狀態管理與組件關係圖解

原子化狀態管理將狀態分解為獨立的小單元（原子/atom），多個組件可以共享同一個原子：

原子層（Atoms）

計數原子

值: 0

主題原子

值: 'dark'

用戶原子

值: { name: 'User' }

組件層（Components）

計數器組件

使用計數原子

使用主題原子

設置組件

使用主題原子

使用用戶原子

用戶資料組件

使用用戶原子

狀態更新時的渲染行為

計數原子更新

值: 0 → 1

主題原子更新

值: 'dark' → 'light'

用戶原子更新

值: 更新用戶名

計數器組件

✓ 重新渲染

設置組件

✗ 不渲染

用戶資料組件

✗ 不渲染

計數器組件

✓ 重新渲染

設置組件

✓ 重新渲染

用戶資料組件

✗ 不渲染

計數器組件

✗ 不渲染

設置組件

✓ 重新渲染

用戶資料組件

✓ 重新渲染

原子化狀態管理的精確渲染：只有訂閱了特定原子的組件才會在該原子更新時重新渲染

原子化狀態管理的優點：

  • 1. 精確更新：只有訂閱特定原子的組件才會重渲染，避免不必要的渲染
  • 2. 共享狀態：多個組件可以共享同一原子，無需層層傳遞props
  • 3. 狀態隔離：不相關的狀態變化不會觸發不必要的重渲染
  • 4. 組合能力：可以從基本原子派生出複雜狀態
  • 5. 測試簡化：每個原子可以獨立測試，無需模擬整個狀態樹

與傳統全局狀態管理相比，原子化狀態管理更靈活、更精細，特別適合UI狀態頻繁變化的複雜應用。

// Jotai示例
import { atom, useAtom } from 'jotai';

// 創建原子狀態
const countAtom = atom(0);
const doubleCountAtom = atom(get => get(countAtom) * 2);

function Counter() {
  const [count, setCount] = useAtom(countAtom);
  const [doubleCount] = useAtom(doubleCountAtom);
  
  return (
    <div>
      <p>計數: {count}</p>
      <p>雙倍計數: {doubleCount}</p>
      <button onClick={() => setCount(c => c + 1)}>增加</button>
    </div>
  );
}

優勢：

  • 1. 精細的重渲染控制，性能優化
  • 2. 可組合的狀態片段
  • 3. 派生狀態和異步支持
  • 4. 代碼拆分友好
  • 5. 原子級別狀態便於測試和維護

適用場景：

  • 1. 數據可視化儀表板（如Google Analytics克隆），需要高效更新多個獨立圖表
  • 2. 協作編輯工具（如Google Docs或Notion克隆），需要精確控制UI更新
  • 3. 即時聊天應用（如Slack或Discord克隆），需處理多個聊天室和通知狀態
  • 4. 股票交易或加密貨幣監控應用，需要高頻率更新多個獨立數據點

🔥 常見面試題目

(一) React中不同狀態管理方案的優缺點是什麼？如何選擇合適的方案？

解答： 讓我們簡單比較各種React狀態管理方案：

狀態管理方案比較

useState/useReducer

✅ 簡單直觀，內建功能

⛔️ 僅限組件內或需提升狀態

適用：表單、計數器等簡單UI

Context API

✅ 避免props drilling，內建功能

⛔️ 全部消費者重渲染，性能問題

適用：主題、用戶認證等低頻更新狀態

Redux

✅ 集中管理，可預測性高，強大工具

⛔️ 模板代碼多，學習曲線陡

// 典型Redux流程 dispatch(action) → reducer → store更新 → UI重渲染

Zustand

✅ API簡潔，包小，性能好

⛔️ 生態不如Redux成熟

// Zustand簡潔API const useStore = create(set => ({ count: 0, increment: () => set(state => ({count: state.count + 1})) }))

Jotai/Recoil

✅ 原子化狀態，細粒度更新

⛔️ 相對較新，最佳實踐少

// Jotai原子化狀態 const countAtom = atom(0) const doubleAtom = atom(get => get(countAtom) * 2)

如何選擇？ 考慮這幾個問題：

  • 1應用規模？ 小型用useState/Context，中型考慮Zustand/Jotai，大型考慮Redux。
  • 2狀態複雜度？ 簡單值用useState or useReducer，複雜對象用第三方庫
  • 3更新頻率？ 高頻更新避免使用Context（牽一髮動全身），考慮Zustand/Jotai
  • 4團隊熟悉度？ 選擇團隊熟悉的技術降低學習成本
  • 5調試需求？ 需要複雜的全局狀態共享選Redux

面試技巧： 不要只說"X最好"，而是展示你理解各方案的權衡，並能根據具體需求選擇合適工具。