React useState 函数式更新面试题整理

1. 总核心思路与更新架构图

核心思路（一句话）

函数式更新把"基于旧状态计算新状态"的逻辑延迟到 React 处理更新队列时执行，从而拿到队列中最新状态，避免函数组件闭包捕获旧状态导致的更新丢失。

React 状态更新架构图（文本版）

text 复制代码

用户事件 / 异步回调 / useEffect
        |
        v
调用 setState(value) 或 setState(updater)
        |
        v
React 创建 update 对象，加入更新队列
        |
        v
调度重新渲染，可能进行批处理
        |
        v
处理更新队列
   |                    |
   | value 形式          | updater 函数形式
   | 新 state = value    | previousState = 上一次更新结果
   |                    | 新 state = updater(previousState)
   |                    |
   +---------+----------+
             |
             v
得到最终 state，重新渲染组件
             |
             v
生成新的闭包，当前渲染读取新 state

主要矛盾与次要矛盾

主要矛盾 ：

函数组件每次渲染都会创建独立闭包，事件或异步回调捕获的是创建时的旧 state；而 React 更新可能批处理、合并、延迟执行，需要基于最新状态计算。直接传值会把计算提前到旧闭包中，函数式更新则把计算延迟到 React 处理队列时。
次要矛盾 ：

依赖数组、性能优化、代码可读性、异步请求竞态、React StrictMode 下 updater 可能被重复调用以检查纯度。

2. 面试题与答案

题目 1：React 中为什么 `useState` 要使用函数式更新？

核心思路：当新状态依赖旧状态时，函数式更新能保证拿到 React 更新队列中的最新状态，避免过时闭包。

原理：

函数组件每次渲染都有自己独立的闭包。
setCount(count + 1) 中的 count 是本次渲染闭包中的旧值，不是调用 setCount 那一刻动态读取的最新值。
如果连续调用多次，或者放在 setTimeout、Promise、useEffect 异步回调中，多个回调可能都捕获同一个旧值。
React 批处理时，后一次更新可能覆盖前一次更新，导致最终只加一次。
setCount(previousCount => previousCount + 1) 会把 updater 函数放入更新队列。
React 按顺序执行 updater，每次 previousCount 都是前一次更新后的最新值。

使用场景：

计数器：setCount(previousCount => previousCount + 1)
切换布尔值：setVisible(previousVisible => !previousVisible)
数组追加：setList(previousList => [...previousList, newItem])
对象合并：setForm(previousForm => ({ ...previousForm, name: '新值' }))
异步回调中更新状态。
连续多次更新同一个状态。

边界场景：

新状态不依赖旧状态时，可以直接传值：setName('张三')。
updater 必须是纯函数，不要在里面发请求、改外部变量、写 DOM。
React StrictMode 开发环境下，updater 可能被调用两次，用来检查是否是纯函数。
如果异步请求存在竞态，函数式更新不能解决"旧请求覆盖新请求"，需要 AbortController 或请求序号。

示例代码：连续三次更新的错误与正确写法

jsx 复制代码

import React, { useState } from 'react';

export default function CounterExample() {
  const [count, setCount] = useState(0);

  // 错误示例：连续三次直接使用当前渲染闭包中的 count。
  const handleWrongTripleIncrement = () => {
    // 假设本次渲染 count 是 0。
    // 三次都计算 0 + 1，得到同一个值 1。
    // React 批处理时后面的值覆盖前面的值，最终只加 1。
    setCount(count + 1);
    setCount(count + 1);
    setCount(count + 1);
  };

  // 正确示例：使用函数式更新，把计算逻辑放入更新队列。
  const handleCorrectTripleIncrement = () => {
    // React 会按顺序执行 updater：
    // previousCount 为 0 时返回 1；
    // 下一次 previousCount 为 1 时返回 2；
    // 再下一次 previousCount 为 2 时返回 3。
    setCount(previousCount => previousCount + 1);
    setCount(previousCount => previousCount + 1);
    setCount(previousCount => previousCount + 1);
  };

  return (
    <div>
      <p>当前计数：{count}</p>
      <button onClick={handleWrongTripleIncrement}>
        错误：连续加三
      </button>
      <button onClick={handleCorrectTripleIncrement}>
        正确：连续加三
      </button>
    </div>
  );
}

更好方案：

如果只是连续加三，也可以合并为一次更新：setCount(previousCount => previousCount + 3)。
复杂状态逻辑推荐 useReducer，例如多个字段相互依赖、状态流转复杂时。
服务端数据缓存、请求竞态、重试等，推荐使用 React Query、SWR 等数据请求库。

题目 2：`useState` 的更新一定是异步的吗？

核心思路 ：setState 调用后当前渲染的 state 不会立即改变，React 会入队并调度渲染；它不是 Promise 异步，而是批处理与调度机制。

准确回答：

调用 setCount 后，不能在当前代码中立即读取到新的 count。

jsx 复制代码

setCount(count + 1);
console.log(count); // 仍然是旧值

React 会把更新加入队列，然后调度重新渲染。
在 React 18 的 createRoot 下，setTimeout、Promise、原生事件中也会自动批处理。
在 React 17 及以前，只有 React 事件处理函数中的更新会默认批处理。
如果需要强制同步刷新，可以使用 flushSync，但很少用，容易影响性能。

使用场景：

面试中要区分"对当前代码表现为异步"和"React 内部调度是批处理"。
不要简单说"setState 是异步的"，更准确说法是： 更新是入队并延迟处理的，当前渲染闭包读不到新值。

边界场景：

多次 setState 可能被合并，只触发一次渲染。
函数式更新可以保证合并时按顺序基于最新状态计算。
直接传值在多次更新时容易丢失中间更新。

题目 3：什么时候应该使用函数式更新？什么时候不用？

核心思路：新状态依赖旧状态时用函数式更新；新状态是独立确定值时直接传值。

应该使用：

setCount(previousCount => previousCount + 1)
setVisible(previousVisible => !previousVisible)
setList(previousList => [...previousList, newItem])
setObject(previousObject => ({ ...previousObject, key: value }))
在 setTimeout、Promise、useEffect 异步回调中更新状态。
短时间内连续多次更新同一个状态。

不需要使用：

setName('张三')
setLoading(true)
setSelectedId(id)
新状态不依赖旧状态，直接传值更清晰。

边界场景：

函数式更新中的 updater 必须是纯函数。
不要在 updater 中执行副作用。
如果状态非常复杂，使用 useReducer 更合适。

题目 4：连续三次 `setCount(count + 1)` 为什么只加一？如何修复？

核心思路 ：三次调用都读取同一个旧闭包值，React 批处理后只保留最终计算值，所以只加一。

原因：

jsx 复制代码

setCount(count + 1);
setCount(count + 1);
setCount(count + 1);

假设当前 count = 0，三次都计算 0 + 1 = 1。

React 批处理时，最终新状态是 1，而不是 3。

修复：

jsx 复制代码

setCount(previousCount => previousCount + 1);
setCount(previousCount => previousCount + 1);
setCount(previousCount => previousCount + 1);

React 会按顺序执行：

text 复制代码

previousCount = 0 -> 返回 1
previousCount = 1 -> 返回 2
previousCount = 2 -> 返回 3

最终结果是 3。

示例代码：异步场景对比

jsx 复制代码

import React, { useState } from 'react';

export default function AsyncCounterExample() {
  const [count, setCount] = useState(0);

  // 错误：异步回调捕获点击时那次渲染的 count。
  const handleWrongAsyncIncrement = () => {
    window.setTimeout(() => {
      // 快速点击两次时，两个回调都读取同一个旧 count。
      // 例如初始为 0，两个回调都执行 setCount(0 + 1)，
      // 最终 count 是 1，而不是期望的 2。
      setCount(count + 1);
    }, 1000);
  };

  // 正确：函数式更新让 React 在执行 updater 时传入最新状态。
  const handleCorrectAsyncIncrement = () => {
    window.setTimeout(() => {
      // 第一个 updater 得到 previousCount=0，返回 1；
      // 第二个 updater 得到 previousCount=1，返回 2。
      setCount(previousCount => previousCount + 1);
    }, 1000);
  };

  return (
    <div>
      <p>当前计数：{count}</p>
      <button onClick={handleWrongAsyncIncrement}>
        错误：一秒后加一
      </button>
      <button onClick={handleCorrectAsyncIncrement}>
        正确：一秒后加一
      </button>
    </div>
  );
}

题目 5：`useEffect` 中异步请求后 `setData([...data, newItem])` 为什么会丢数据？

核心思路 ：data 是本次 useEffect 执行时闭包捕获的旧数组，异步请求返回后直接使用旧 data 追加，会覆盖期间其他更新。函数式更新可基于最新 data 追加。

错误代码问题：

jsx 复制代码

useEffect(() => {
  async function fetchData() {
    const newItem = await fetchDataById(id);
    setData([...data, newItem]); // data 是旧闭包值
  }
  fetchData();
}, [id]);

依赖数组只有 id，没有 data，这是为了避免每次 data 变化都重新请求。
但异步回调中的 data 是 useEffect 执行时捕获的旧值。
快速切换 id 时，多个请求返回后都基于同一个旧 data 追加，导致丢失中间数据。

正确写法：

jsx 复制代码

setData(previousData => [...previousData, newItem]);

边界场景：

函数式更新只解决"基于最新 data 追加"。
如果快速切换 id，旧请求可能比新请求更晚返回，造成请求竞态。
需要用 AbortController 取消旧请求，或使用请求序号忽略旧响应。

完整示例代码：函数式更新 + 取消请求

jsx 复制代码

import React, { useEffect, useState } from 'react';

// 模拟根据 id 获取数据。真实项目中替换为 fetch 或 axios。
function fetchDataById(id, signal) {
  return new Promise((resolve, reject) => {
    const timer = window.setTimeout(() => {
      resolve({ id, name: `数据 ${id}` });
    }, 500);

    // 如果请求被取消，清除定时器并拒绝 Promise。
    signal.addEventListener('abort', () => {
      window.clearTimeout(timer);
      const error = new Error('请求已取消');
      error.name = 'AbortError';
      reject(error);
    });
  });
}

export default function DataListExample() {
  const [id, setId] = useState(1);
  const [data, setData] = useState([]);
  const [loading, setLoading] = useState(false);

  useEffect(() => {
    const abortController = new AbortController();

    async function loadData() {
      try {
        setLoading(true);
        const newItem = await fetchDataById(id, abortController.signal);

        // 正确：函数式更新，基于最新 data 追加，避免过时闭包。
        setData(previousData => [...previousData, newItem]);
      } catch (error) {
        if (error.name !== 'AbortError') {
          console.error('加载数据失败：', error);
        }
      } finally {
        // 只有未被取消的请求才关闭 loading，避免旧请求影响新请求。
        if (!abortController.signal.aborted) {
          setLoading(false);
        }
      }
    }

    loadData();

    return () => {
      // id 变化或组件卸载时取消旧请求，避免请求竞态。
      abortController.abort();
    };
  }, [id]);

  return (
    <div>
      <button onClick={() => setId(previousId => previousId + 1)}>
        下一项
      </button>
      {loading && <p>加载中...</p>}
      <ul>
        {data.map((item, index) => (
          <li key={`${item.id}-${index}`}>{item.name}</li>
        ))}
      </ul>
    </div>
  );
}

更好方案：

请求竞态：使用 AbortController、请求序号、忽略旧响应。
服务端数据：使用 React Query、SWR，它们内置缓存、竞态处理、重试。
复杂本地状态：使用 useReducer，把多个更新动作集中管理。

题目 6：函数式更新的原理、边界和常见误区是什么？

核心思路：函数式更新是 React 更新队列中的 updater，React 按顺序执行，每次传入前一次更新后的最新状态。

原理补充：

setState(value)：把值直接作为新状态。
setState(updater)：把函数放入更新队列。
React 处理队列时，按顺序调用 updater。
每次 updater 的 previousState 是上一次 updater 返回的结果。
最终 state 用于下一次渲染。

常见误区：

误区一：setState 是 Promise 异步。
纠正：不是 Promise 异步，是 React 调度与批处理，当前渲染读不到新值。
误区二：只有异步回调才需要函数式更新。
纠正：连续同步更新、批处理、依赖旧状态时都需要。
误区三：函数式更新能解决所有异步问题。
纠正：它只解决旧状态闭包问题，不解决请求竞态、组件卸载后更新等问题。
误区四：updater 可以写副作用。
纠正：updater 必须是纯函数，StrictMode 下可能被重复调用。

边界场景：

新状态不依赖旧状态，直接传值。
复杂状态用 useReducer。
服务端状态用 React Query 或 SWR。
需要同步刷新时用 flushSync，但要谨慎。

3. 满分答案

useState 的函数式更新用于在新状态依赖旧状态时，避免过时闭包导致更新丢失。函数组件每次渲染都会创建独立闭包，事件或异步回调捕获的是创建时的 state。直接写 setCount(count + 1)，在连续调用、异步回调、批处理中，多个更新都会基于同一个旧值计算，最终被合并覆盖；例如连续三次 setCount(count + 1)，初始为 0 时最终只加 1。函数式写法 setCount(previousCount => previousCount + 1) 会把 updater 放入 React 更新队列，React 按顺序执行，每个 previousCount 都是前一次更新后的最新值，所以连续三次会加 3，快速点击两次异步加一也会正确加 2。

useState 的更新对当前代码表现为异步：调用 setState 后，当前渲染中的 state 不会立即变化，React 会批处理并调度重新渲染；React 18 的 createRoot 下，Promise、setTimeout、原生事件也会自动批处理。使用场景包括计数器、切换布尔值、数组追加、对象合并、异步请求后更新、useEffect 中基于旧状态更新。边界场景包括：新状态不依赖旧状态时直接传值；updater 必须是纯函数；StrictMode 开发环境可能重复调用 updater；异步请求竞态要用 AbortController 或忽略旧响应；复杂状态用 useReducer；服务端状态用 React Query 或 SWR。主要矛盾是函数组件闭包捕获旧状态与 React 更新队列需要最新状态之间的冲突；次要矛盾是依赖数组、性能、可读性和请求竞态。核心结论：只要新状态依赖旧状态，尤其是连续更新或异步回调中，就使用函数式更新。

React useState 函数式更新面试题整理

1. 总核心思路与更新架构图

核心思路（一句话）

React 状态更新架构图（文本版）

主要矛盾与次要矛盾

2. 面试题与答案

题目 1：React 中为什么 useState 要使用函数式更新？

题目 2：useState 的更新一定是异步的吗？

题目 3：什么时候应该使用函数式更新？什么时候不用？

题目 4：连续三次 setCount(count + 1) 为什么只加一？如何修复？

题目 5：useEffect 中异步请求后 setData([...data, newItem]) 为什么会丢数据？

题目 6：函数式更新的原理、边界和常见误区是什么？

3. 满分答案

题目 1：React 中为什么 `useState` 要使用函数式更新？

题目 2：`useState` 的更新一定是异步的吗？

题目 4：连续三次 `setCount(count + 1)` 为什么只加一？如何修复？

题目 5：`useEffect` 中异步请求后 `setData([...data, newItem])` 为什么会丢数据？