你有没有遇到过这样的困惑：明明修改了变量，可页面纹丝不动；明明调用了更新方法，怎么打印出来的还是旧值？这一切的背后，都指向 React 中最基础、也最容易被误解的 Hook——`useState`。今天我们不背 API，而是从“快照”的心智模型出发，把它的脾气摸透，让你不仅能写对，还能讲出为什么。

1. 一张图带你跳出“变量”的思维陷阱

先用一个按钮计数的例子开局：
 

function Counter() {
  let count = 0;

  function handleClick() {
    count = count + 1;
    console.log(count);
  }

  return (
    <button onClick={handleClick}>
      点击了 {count} 次
    </button>
  );
}

你点击按钮，控制台会乖乖打印 1、2、3……但页面上的“点击了 0 次”永远不变。为什么？因为 React 组件只是一个函数，它只有在“被要求重新执行”时才会产生新的界面描述（JSX）。普通变量 `count` 的改变并不会触发重新执行，页面自然无动于衷。

那如何才能让 React “主动”重新执行组件函数？我们需要一个 React 能够感知到的特殊变量——状态。

 2. useState 的基本打开方式

把上面的代码用 `useState` 改写：

import { useState } from 'react';

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

  function handleClick() {
    setCount(count + 1);
  }

  return (
    <button onClick={handleClick}>
      点击了 {count} 次
    </button>
  );
}

现在点击按钮，数字跳动起来了。`useState(0)` 做了三件事：
- 在组件函数第一次执行时，把 `0` 注册为状态的初始值；
- 返回一个数组，第一个值是当前状态（这里是 `count`），第二个值是更新函数（这里是 `setCount`）；
- 当调用更新函数时，React 会安排一次新的渲染，即重新执行整个组件函数，这一次 `count` 会拿到新值。

语法上，我们用数组解构来命名，这只是惯例，并不是魔法。你可以叫它 `[apple, setApple]`，只要一致即可。初始值可以是数字、字符串、布尔值、对象、数组，甚至是一个函数（后面会讲）。

---

 💡 1：每一次渲染，都有一张独立的“快照”

这才是本文的精髓。很多人卡在 `useState` 的异步行为上，就是因为他们把状态想象成一个盒子，修改变量就是替换盒子里的东西。但真实的心智模型是：状态更像是一张随着渲染被固定的照片，而不是一个随时可变的盒子。

当这段代码运行时：

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

function handleClick() {
  setCount(count + 1);
  console.log(count); // 还是旧值！
}

你点击一次按钮，`count` 打印出来依旧是 `0`，而不是 `1`。因为当前这次渲染“拍下”的快照里，`count` 的值是固定的 `0`。`setCount(count + 1)` 并不是在修改这张照片里的数字，而是告诉 React：“请用新值 `0 + 1` 去安排下一次渲染，在那次渲染的快照里，`count` 会是 `1`。”

这就是为什么 `setCount` 调用后立即读取 `count` 拿不到新值——你仍然活在当前的快照中，新快照还没生成。这种“快照”模型是 React 函数式思想的基石：组件就是状态到 UI 的纯函数`UI = f(state)`，给定同一个状态，渲染出来的 UI 一定相同。

一旦理解快照，很多怪异现象就变得理所当然。比如，同一个事件处理函数里连续调用两次 `setCount(count + 1)` 只会让数字增加 `1`，而不是 `2`。因为两次读取的 `count` 都来自当前快照，两次 `setCount` 交给 React 的都是“新值为 `0 + 1`”，React 会按最终一致的值去更新，于是只加了一次。

---

💡  2：函数式更新——让状态更新脱离当前快照

如果下次状态需要依赖上一次的状态值，我们就得换一种更新方式，它不读取当前快照里的 `count`，而是给 React 一个“变换函数”：

setCount(prevCount => prevCount + 1);

React 会把这个函数放入队列，待渲染时，把最新的状态值作为 `prevCount` 传进去，然后计算出新状态。这样连续调用三次 `setCount(prev => prev + 1)`，React 会依次执行变换，最终让数字增加 `3`。

函数式更新相当于在说：“不管最新的状态是什么，请在这个基础上加 1。”它摆脱了对当前快照的依赖，是处理基于旧值更新最安全的手段。

这也解释了为什么 React 推荐函数式更新：它符合纯函数的哲学，不读取外部可变状态，只根据输入计算输出。即便未来 React 调度机制再变，这种写法也不会出错。

💡 独特见解 3：批处理——为什么 React 要把多次更新“打包”？

React 默认会把同一事件处理函数中的多次状态更新合并成一次渲染。比如下面这个例子（在 React 18 中）：

function handleClick() {
  setCount(c => c + 1);
  setName('Alice');
  setAge(a => a + 1);
}

即便触发了三个 `set*`，组件也只会重新渲染一次。这是因为 React 很聪明：重新渲染是有成本的，它希望收集完所有状态变化，一次性计算新的 UI，减少不必要的浏览器回流与重绘。

React 18 更是将自动批处理扩展到了异步操作、`setTimeout`、原生事件等场景中。对开发者来说，这几乎是透明的，但理解它的存在有助于你明白：状态更新是“异步调度”的，你无法在调用了 `setCount` 之后立即依赖 DOM 中已更新的值。如果确实需要，可以使用 `useEffect` 监听状态变化。

同时，批处理也再次印证了“快照”模型——在本次渲染中，无论你安排多少次更新，当前代码看见的 `count` 始终不变。写代码时你只需要关心“下一次渲染应该是什么状态”，而不是“如何立刻改变这个变量”。

4. 不可变性：为什么直接修改对象/数组是“禁区”？

来看一个易错点：

const [user, setUser] = useState({ name: 'Alice', age: 20 });

function handleBirthday() {
  user.age = 21;        // 直接修改了原对象
  setUser(user);        // 触发更新
}

页面很可能不更新。因为 React 用 `Object.is` 来比较新旧状态是否相同。你传入的 `user` 和旧 `user` 指向同一个对象引用，React 认为状态没变，于是跳过渲染。

状态的更新必须替换整个值，而不是在原来的值上修改。 对于对象和数组，我们要创建副本：

// 正确姿势：展开运算符创建新对象
setUser({ ...user, age: 21 });

// 数组同理：concat、filter、map、展开等产生新数组
setItems([...items, newItem]);

这种“不可变数据”并不是 React 在刁难你，它带来两大好处：
- 性能优化：引用比较比深比较快得多，React 能迅速判断状态是否变化。
- 可预测性：状态像历史记录一样无法被篡改，方便调试、回溯和实现时间旅行。

你可以把它想象成记账：你不能把昨天的账本直接涂改，而是登记一条新记录，这样账目始终清晰可信。

5. 惰性初始化：别让初始值拖慢首屏

如果初始状态需要复杂计算，比如从 `localStorage` 解析大数据，直接传值会让每次渲染都重新计算一次（虽然 React 会忽略后续渲染的初始值参数，但计算本身依然会执行）：

const [data, setData] = useState(expensiveComputation()); // 浪费

这时候可以传入一个初始化函数，React 只会在首次渲染时调用它，后续不会再执行：

const [data, setData] = useState(() => expensiveComputation());

这个小优化在性能敏感场景非常实用，也体现了 React 对细节的考究。

6. 避坑指南：Hook 规则与常见错误

`useState` 是一个 Hook，它的内部运作依赖于调用顺序。React 会在组件每次渲染时，按相同的顺序获取对应的状态。因此绝对不能把 `useState` 写在条件、循环或嵌套函数里：

// ❌ 错误：条件式调用会打乱顺序
if (someCondition) {
  const [value, setValue] = useState(0);
}

必须无条件地写在函数组件的顶层。这保证了每次渲染时 Hook 的数量和顺序一致，状态才能正确匹配。

另外，避免不必要的状态。如果一个值可以由现有状态或 props 计算出来，就不要另设一个状态，否则你得费力保持同步。比如 `fullName` 如果总由 `firstName` 和 `lastName` 拼接得来，直接计算就行，不必用 `useState`。

总结：把状态当成快照，而不是盒子

回顾一下，`useState` 远不止是“在函数组件里加一个变量”那么简单。它背后是一整套函数式渲染哲学：

- 状态是每一次渲染的快照，函数组件根据快照生成 UI；
- 更新状态是安排下一次渲染，而不是修改当前值；
- 函数式更新让你基于最新值进行变换，避开快照闭包；
- 不可变性保证变化可追踪、性能易优化；
- 批处理机制合并更新，提升页面效率。

当你把“盒子模型”从脑中卸载，装进“快照模型”时，那些曾经诡异的 `useState` 行为都会变得自然合理。这个思维转变一旦完成，你不仅掌握了 `useState`，更拿到了理解 React 整个生态的钥匙。接下来，再去探索 `useEffect`、`useRef`，你会发现自己早已站在了更高的起点上。