面试题：React 中 useReducer 和 useState 有什么区别？什么时候应该使用 useReducer？

一、核心结论与决策流程

核心思路一句话：

useState 管简单、独立、更新直接的状态；useReducer 管复杂、关联、多事件源、更新逻辑集中、需要稳定 dispatch 和强测试的状态；全局状态用 Redux Toolkit、Zustand、Jotai、Recoil 等专业工具。

主要矛盾：

状态复杂度与工具选择是否匹配。

次要矛盾：

性能优化、可测试性、跨层级传递、团队规范、调试体验。

决策流程图（文本版）

开始
  |
状态是否简单、独立、更新逻辑直接？
  | 是 -> useState
  | 否
多个状态是否互相关联 / 一个操作更新多个状态 / 更新依赖前置状态？
  | 是 -> useReducer
  | 否 -> useState
状态更新逻辑是否分散在多个事件处理器中？
  | 是 -> useReducer
  | 否 -> useState
是否需要把多个 setter 函数深层传递给子组件？
  | 是 -> useReducer，只传一个稳定 dispatch
  | 否 -> useState
是否需要跨多层组件共享？
  | 是 -> useReducer + Context（拆分 State/Dispatch Context）或专业状态库
  | 否 -> 组件内 useReducer
是否是大型应用全局状态？
  | 是 -> Redux Toolkit / Zustand / Jotai / Recoil
  | 否 -> 局部 useReducer

架构图（文本版）

界面事件
  |
dispatch(action)
  |
reducer(currentState, action)
  |
newState
  |
React 调度重新渲染
  |
界面更新

关键点：
1. action 是"发生了什么"的对象，通常含 type 和 payload。
2. reducer 是纯函数：相同输入必得相同输出，不修改原状态，不发起请求，不修改外部变量。
3. dispatch 引用稳定，适合传给 React.memo 子组件。
4. useReducer 与 Redux 思想相似，但通常作用域是组件级或 Context 有限共享，不是 Redux 替代品。

二、面试题与答案

面试题 1：useState 和 useReducer 有什么区别？

核心思路：

useState 是简单状态声明式更新；useReducer 是把状态更新逻辑收敛到 reducer 的集中式状态机。

对比表：

维度	useState	useReducer
适用状态	简单、独立、少量状态	复杂对象、多个关联子值、状态机
更新方式	直接 setState	dispatch(action)
逻辑位置	分散在事件处理器	集中在 reducer
跨层级传递	可能传多个 setter	只传一个稳定 dispatch
可测试性	依赖组件测试	reducer 纯函数易单元测试
调试	简单直观	action 语义清晰，便于追踪
全局能力	无	配合 Context 做有限共享，不是全局方案
性能	简单状态更轻	不一定更快，dispatch 稳定有利于 React.memo

实现原理：

React 内部 useState 可以看作 useReducer 的简化特例。useState 返回当前状态和更新函数，更新函数把新值加入更新队列；useReducer 返回当前状态和 dispatch，dispatch 把 action 加入队列，渲染时按顺序调用 reducer 计算新状态。React 会批处理多个更新。

使用场景：

开关、输入框值、简单计数器用 useState；复杂表单、购物车、多步骤流程、状态机用 useReducer。

边界场景：

reducer 必须纯函数；不能直接修改 state；异步请求不能写在 reducer 里。

示例代码：useState 简单开关

import React, { useState } from 'react';

export default function Toggle() {
  // 简单独立布尔状态，useState 最直接
  const [isOn, setIsOn] = useState(false);

  return (
    <button onClick={() => setIsOn((previous) => !previous)}>
      {isOn ? '开' : '关'}
    </button>
  );
}

---

面试题 2：什么时候应该使用 useReducer？

核心思路：

当状态更新逻辑开始复杂、分散、互相关联，或者需要把更新能力稳定传给深层子组件时，用 useReducer。

典型信号：

1. 一个状态对象包含多个子值。
2. 下一个状态依赖前一个状态，且逻辑复杂。
3. 一个操作同时更新多个状态。
4. 多个事件处理器修改同一组状态，逻辑分散。
5. 需要把多个 setter 函数深层传递，props 冗长。
6. 核心状态逻辑需要独立单元测试。
7. 预见到该组件状态会持续变复杂。

边界：

1. 只有一两个独立布尔值、字符串、数字时，不要硬用 useReducer。
2. 全局状态不要用 useReducer + Context 硬扛，优先 Redux Toolkit、Zustand、Jotai、Recoil。
3. reducer 中不能有副作用。

示例代码：复杂表单 useReducer

import React, { useReducer } from 'react';

// 状态结构：多个字段互相关联
const initialState = {
  username: '',
  phone: '',
  phoneValid: false,
  submitAttempted: false,
};

// reducer 是纯函数：根据当前状态和 action 返回新状态
function formReducer(state, action) {
  switch (action.type) {
    case 'UPDATE_USERNAME':
      // 不可变更新：返回新对象，不直接修改原 state
      return {
        ...state,
        username: action.payload,
      };

    case 'UPDATE_PHONE':
      // 手机号变化时，同时重置校验状态，体现关联状态集中处理
      return {
        ...state,
        phone: action.payload,
        phoneValid: false,
      };

    case 'VALIDATE_PHONE':
      return {
        ...state,
        phoneValid: /^1[3-9]\d{9}$/.test(state.phone),
      };

    case 'SUBMIT':
      return {
        ...state,
        submitAttempted: true,
      };

    case 'RESET':
      return initialState;

    default:
      return state;
  }
}

export default function ComplexForm() {
  const [state, dispatch] = useReducer(formReducer, initialState);

  return (
    <form
      onSubmit={(event) => {
        event.preventDefault();
        // 异步请求不要放在 reducer 中，应先 dispatch 校验，再发请求
        dispatch({ type: 'VALIDATE_PHONE' });
        dispatch({ type: 'SUBMIT' });
      }}
    >
      <input
        value={state.username}
        onChange={(event) =>
          dispatch({ type: 'UPDATE_USERNAME', payload: event.target.value })
        }
        placeholder="用户名"
      />

      <input
        value={state.phone}
        onChange={(event) =>
          dispatch({ type: 'UPDATE_PHONE', payload: event.target.value })
        }
        placeholder="手机号"
      />

      {state.submitAttempted && !state.phoneValid && (
        <p>手机号格式不正确</p>
      )}

      <button type="submit">提交</button>
      <button type="button" onClick={() => dispatch({ type: 'RESET' })}>
        重置
      </button>
    </form>
  );
}

---

面试题 3：useReducer 的核心优势是什么？

核心思路：

集中管理复杂状态、稳定 dispatch、纯函数可测试、action 流清晰。

四个核心优势：

1. 复杂状态集中管理

   所有状态转换规则都放在 reducer 中，通过 action.type 区分，代码意图更明显。

2. 稳定 dispatch，利于性能优化

   React 保证 dispatch 引用稳定。传给 React.memo 子组件时，不会因为父组件重新渲染导致子组件无意义重渲染。

3. 纯函数 reducer，易单元测试

   reducer 不依赖外部状态，无副作用，给定相同输入必得相同输出。可以脱离组件测试。

4. 清晰的 action 流

   dispatch({ type: 'UPDATE_PHONE', payload }) 能明确表达"发生了什么"和"携带什么数据"，便于调试和追踪。

示例代码：稳定 dispatch 配合 React.memo

import React, { useReducer, React.memo } from 'react';

function counterReducer(state, action) {
  switch (action.type) {
    case 'INCREMENT':
      return { count: state.count + 1 };
    case 'DECREMENT':
      return { count: state.count - 1 };
    default:
      return state;
  }
}

// 子组件只接收 dispatch，dispatch 引用稳定
const CounterButton = React.memo(function CounterButton({ dispatch }) {
  console.log('CounterButton 渲染');

  return (
    <button onClick={() => dispatch({ type: 'INCREMENT' })}>
      加一
    </button>
  );
});

export default function CounterParent() {
  const [state, dispatch] = useReducer(counterReducer, { count: 0 });

  return (
    <div>
      <div>计数：{state.count}</div>
      {/* 父组件 state 变化时，CounterButton 的 props 中 dispatch 没变，因此不会重渲染 */}
      <CounterButton dispatch={dispatch} />
    </div>
  );
}

---

面试题 4：面试中被问到"useReducer 和 useState 怎么选"，如何回答？

核心思路：

先定义，再对比，再给场景，再讲优势，最后讲边界和 Redux 区别。

推荐回答结构：

1. useState 适合简单、独立、更新直接的状态。
2. useReducer 适合复杂对象、多个关联子值、更新依赖前置状态、多个事件源修改同一组状态。
3. useReducer 优势：集中 reducer、稳定 dispatch、纯函数易测试、action 流清晰。
4. 性能上不能绝对说 useReducer 更好，简单状态 useState 更轻。
5. useReducer 不是 Redux 替代品，它通常是组件级或 Context 有限共享。
6. 实际选型：默认 useState，复杂后重构 useReducer；全局状态用 Redux Toolkit、Zustand、Jotai、Recoil。

边界：

不要为了用而用，不要过度设计。

---

面试题 5：useReducer 和 Redux 有什么关系和区别？

核心思路：

思想相似，作用域不同。useReducer 是组件内状态管理 Hook，Redux 是全局状态管理生态。

相同点：

1. 都使用 action 描述发生了什么。
2. 都使用 reducer(currentState, action) 计算新状态。
3. 都强调纯函数、不可变更新、单向数据流。

不同点：

1. useReducer 是 React 内置 Hook，作用域通常是单个组件或配合 Context 做有限共享。
2. Redux 是独立状态管理库，适合大型应用全局状态。
3. Redux 有中间件、Redux DevTools、异步方案、生态工具。
4. useReducer 没有全局 store，不是 Redux 替代品。

更好方案：

大型全局状态用 Redux Toolkit；轻量全局状态用 Zustand；原子化状态用 Jotai、Recoil；服务端状态用 TanStack Query、SWR。

---

面试题 6：useReducer 的性能一定比 useState 好吗？

核心思路：

不一定。dispatch 稳定有优化潜力，但 useReducer 增加了抽象层，简单状态反而更重。

正确理解：

1. dispatch 引用稳定，适合传给 React.memo 子组件。
2. 如果使用 useState 并传递内联箭头函数，每次渲染函数引用变化，可能导致子组件重渲染。
3. 但简单状态用 useReducer 会增加代码量和心智负担。
4. 性能优化要结合具体场景，不能绝对化。

边界：

如果只是开关、输入框值，useState 通常是最优解。

---

面试题 7：useReducer + Context 能替代 Redux 吗？

核心思路：

中小型跨组件共享可以，大型全局状态不建议直接替代 Redux。

实现原理：

useReducer 管理状态，Context 把 state 和 dispatch 跨层级传下去。但 Context 的 value 变化会导致所有消费者重渲染。

优化方式：

1. 拆分 StateContext 和 DispatchContext。
2. 只使用 dispatch 的组件不订阅 state。
3. 使用 React.memo、useMemo。
4. 大型应用用 Redux Toolkit、Zustand、Jotai、Recoil。

示例代码：useReducer + Context 拆分

import React, {
  createContext,
  useContext,
  useReducer,
  useMemo,
} from 'react';

const initialState = { count: 0 };

function counterReducer(state, action) {
  switch (action.type) {
    case 'INCREMENT':
      return { count: state.count + 1 };
    case 'DECREMENT':
      return { count: state.count - 1 };
    case 'RESET':
      return initialState;
    default:
      return state;
  }
}

// 拆分 State 和 Dispatch，避免只用 dispatch 的组件因 state 变化而重渲染
const CounterStateContext = createContext(null);
const CounterDispatchContext = createContext(null);

export function CounterProvider({ children }) {
  const [state, dispatch] = useReducer(counterReducer, initialState);

  // dispatch 本身稳定，这里包一层 useMemo 是为了符合 Context value 稳定习惯
  const dispatchValue = useMemo(() => dispatch, [dispatch]);

  return (
    <CounterStateContext.Provider value={state}>
      <CounterDispatchContext.Provider value={dispatchValue}>
        {children}
      </CounterDispatchContext.Provider>
    </CounterStateContext.Provider>
  );
}

export function useCounterState() {
  const context = useContext(CounterStateContext);
  if (context === null) {
    throw new Error('useCounterState 必须在 CounterProvider 内使用');
  }
  return context;
}

export function useCounterDispatch() {
  const context = useContext(CounterDispatchContext);
  if (context === null) {
    throw new Error('useCounterDispatch 必须在 CounterProvider 内使用');
  }
  return context;
}

export function CounterDisplay() {
  const state = useCounterState();
  return <div>计数：{state.count}</div>;
}

export function CounterButtons() {
  const dispatch = useCounterDispatch();
  return (
    <div>
      <button onClick={() => dispatch({ type: 'INCREMENT' })}>加一</button>
      <button onClick={() => dispatch({ type: 'DECREMENT' })}>减一</button>
      <button onClick={() => dispatch({ type: 'RESET' })}>重置</button>
    </div>
  );
}

---

面试题 8：实际开发中如何从 useState 重构到 useReducer？

核心思路：

默认从 useState 开始；当出现"多个 setState 联动、一个操作更新多个状态、逻辑分散、深层传 setter、需要单元测试"时，重构为 useReducer。

重构信号：

1. 你定义了好几个 useState。
2. 一个操作同时更新多个状态。
3. 下一个状态严重依赖前一个状态。
4. 更新逻辑散落在多个事件函数中。
5. 需要把多个 setter 函数往下传好几层。
6. 状态转换逻辑需要独立测试。

更好方案：

复杂业务逻辑可抽离 reducer 到单独文件；不可变更新复杂时可用 Immer，但原生 useReducer 不内置 Immer，需要自己引入。

---

面试题 9：useReducer 有哪些边界和坑？

核心思路：

reducer 必须纯、必须不可变更新、异步放外面、不要过度设计、注意 Context 性能。

常见坑：

1. 在 reducer 中直接修改 state，导致 React 不触发更新或行为异常。
2. 在 reducer 中发请求、读写 localStorage、修改外部变量，破坏纯函数。
3. 在 reducer 中执行异步逻辑，应该先 dispatch 开始状态，异步完成后再 dispatch 成功或失败。
4. React StrictMode 开发环境可能双调用 reducer 来检测副作用，因此 reducer 必须纯。
5. 简单状态硬用 useReducer，增加心智负担。
6. useReducer + Context 的 value 未拆分，导致所有消费者重渲染。
7. 误以为 useReducer 是 Redux 替代品。
8. 忘记 default 分支，遇到未知 action 返回原状态。

异步正确写法：

async function handleSave() {
  dispatch({ type: 'SAVE_START' });

  try {
    const result = await api.save(state);
    dispatch({ type: 'SAVE_SUCCESS', payload: result });
  } catch (error) {
    dispatch({ type: 'SAVE_ERROR', payload: error });
  }
}

惰性初始化：

如果初始状态计算昂贵，使用第三个参数 init。

function init(initialCount) {
  return { count: initialCount };
}

const [state, dispatch] = useReducer(reducer, props.initialCount, init);

---

面试题 10：如何测试 useReducer？

核心思路：

reducer 是纯函数，可以脱离组件独立测试。

示例代码：reducer 单元测试

import { formReducer } from './ComplexForm';

test('UPDATE_PHONE 应更新手机号并重置校验状态', () => {
  const previousState = {
    username: '方格',
    phone: '13800000000',
    phoneValid: true,
    submitAttempted: false,
  };

  const action = {
    type: 'UPDATE_PHONE',
    payload: '139',
  };

  const nextState = formReducer(previousState, action);

  expect(nextState).toEqual({
    username: '方格',
    phone: '139',
    phoneValid: false,
    submitAttempted: false,
  });
});

原理：

纯函数没有副作用，不依赖 React 渲染，不依赖真实浏览器事件，因此测试稳定、快速、可预测。

---

三、核心知识点补充

1. useState 本质

   可以看作 useReducer 的简化版。React 内部用类似 reducer 的机制处理状态更新。

2. dispatch 稳定性

   React 保证 dispatch 引用稳定，重新渲染不会改变。它适合传给 React.memo 子组件。不要错误理解为"只有 reducer 或初始状态不变才稳定"。

3. action 设计

   action 通常包含 type 和 payload。type 表示操作类型，payload 表示携带数据。type 要语义化，例如 UPDATE_PHONE、VALIDATE_PHONE。

4. 不可变更新

   reducer 必须返回新对象或新数组，不能直接修改原状态。常用展开运算符、map、filter、concat。复杂场景可用 Immer。

5. React.memo

   如果子组件只接收稳定 dispatch，配合 React.memo 可以避免父组件状态变化导致子组件无意义重渲染。

6. Context 性能

   useReducer + Context 可以实现跨组件共享，但 Context 的 value 变化会通知所有消费者。拆分 StateContext 和 DispatchContext 是常见优化。

7. 全局状态选型

   大型全局状态用 Redux Toolkit；轻量全局状态用 Zustand；原子化状态用 Jotai、Recoil；服务端状态用 TanStack Query、SWR；复杂表单用 React Hook Form。

8. 不要过度设计

   没有绝对更好的 Hook，只有更适合当前场景的选择。

---

四、满分答案

面试官您好，useState 和 useReducer 都是 React 管理组件状态的内置 Hook。

useState 适合简单、独立、更新逻辑直接的状态，比如开关、输入框值、简单计数器。它语法直观，一行代码就能声明和更新状态。

useReducer 更适合复杂状态管理。当状态是一个复杂对象、包含多个互相关联的子值、下一个状态依赖前一个状态、多个事件源修改同一组状态，或者更新逻辑分散在多个事件处理器中时，useReducer 更有优势。它的数据流是：界面事件触发 dispatch(action)，reducer 根据当前状态和 action 计算新状态，然后 React 重新渲染。

useReducer 的核心优势有四个：第一，复杂状态集中管理，所有状态转换规则都在 reducer 中，通过 action type 区分，代码更清晰；第二，dispatch 引用稳定，React 保证它不会在重新渲染时改变，传给 React.memo 子组件有助于避免不必要的重渲染；第三，reducer 是纯函数，相同输入必得相同输出，没有副作用，非常容易做单元测试；第四，action 流清晰，每次状态更新的意图都能被明确描述。

但要注意，不能绝对说 useReducer 性能一定比 useState 好。简单状态用 useReducer 会增加抽象层和心智负担。实际选型中，我通常默认从 useState 开始，当发现多个 useState 联动、一个操作更新多个状态、更新逻辑分散、需要深层传递多个 setter，或者核心状态逻辑需要独立测试时，再重构为 useReducer。

useReducer 和 Redux 思想相似，都使用 action 和 reducer，但 useReducer 通常是组件级状态管理，或者配合 Context 做有限跨组件共享，它不是 Redux 的替代品。大型全局状态更适合 Redux Toolkit、Zustand、Jotai、Recoil 等专业工具。使用 useReducer 时，reducer 必须纯，不能直接修改 state，不能发请求，异步逻辑要放在事件处理函数或副作用中，完成后再 dispatch。总之，选择的关键是评估状态复杂度、更新逻辑分布、可维护性、可测试性和跨层级传递需求。没有绝对更好的方案，只有更适合当前场景的方案。