主要结论

React 的状态管理遵循三条铁律，理解它们就能避开 90% 初学者的坑

1. 状态的初始化只应在「挂载时」执行一次昂贵计算必须用惰性初始化。
2. 状态的更新是异步且批量的依赖旧值时必须使用 updater 函数。
3. 能算出来的东西永远不要存成状态——派生状态是消除 bug 的最有效手段。

下面自顶向下逐层拆解。

说到第一层。惰性初始化——别在每次渲染时重复计算

从问题来看，你的初始化逻辑跑了几次？

看下面这段代码：

const = useState);// ❌ 每次渲染都执行

直觉上，useState 的初始值只在「第一次渲染」时被使用。但 JavaScript 在调用函数前，会先对所有实参求值。这代表着 heavyComputation 会在每次渲染时被调用——React 只是忽略了除第一次之外的结果。

对于生成 10。000 条使用者数据 的 heavyComputation这代表着每敲一个字符触发重渲染，就白白跑了 10,000 次循环。

至于解法，传函数。别传值

const = useState => heavyComputation);// ✅ 只在挂载时执行

当你传入一个函数时React 将其视为「惰性初始化器」——只在组件挂载时调用一次. 后续重渲染中，这个函数被完全跳过。

什么时候需要惰性初始化？

一句话规则：If initial value requires a function call that isn’t O,wrap it in a lazy initializer.

说到第二层，异步更新与批量合并——setState 不是普通 setter

至于直觉陷阱，点击后 count 会是多少？说起来，

const = useState;const addCount = => {
setCount;// count = 0 → 期望变成 1
setCount;// count = 0 → 期望变成 2
setCount;
按理说，// count = 0 → 期望变成 3
};
其实，

实际结果：点击后 count 成为 1 而非 3.

为什么？

• A. 当前闭包中的 {count} 是本次渲染的快照，不会在函数执行期间改变。
• B. 三次 {setCount} 都基于同一个快照进行计算：{0 + 1}.
• C. React 把这三次更新合并为一次：最终 state 为 {1}.

This design mirrors native DOM batch update pattern:

// test.html —— 原生 DOM 的批量更新思想
const fragment = document.createDocumentFragment;for {
const item = document.createElement;老实说，item.innerText = task;fragment.appendChild;// 暂存到内存中
}
oList.appendChild;
// 一次性插入真实 DOM，只触发一次回流

The same principle applies at framework level: multiple state updates are collected and applied in a single render pass。avoiding costly intermediate renders.

正确做法这方面，updater 函数

setCount;setCount，setCount;// prev 在每一次调用时都是最新的值 → 最终得到 3

The updater receives **latest** state after previous updates have been applied,guaranteeing correct accumulation even when calls are batched.

决策规则 📊

新状态是否依赖旧状态？├─ 否 → setState
└─ 是 → setState

P.S.: 当不确定是否依赖旧值时一律使用 updater 函数。老实说，它永远不会因为闭包捕获而出错。

从第三层来看，派生状态——能算出来的别存成 state！🎯

一个反直觉的事实：

The more independent pieces of state you keep。higher chance of bugs. Each additional piece introduces a “keep‑in‑sync” responsibility:

The highest level of state management is **not managing extra state at all**—instead compute values on‑‑fly.

实践案例这方面，App.jsx 中的唯一数据源 & 派生值

const = useState => heavyComputation);不过，// 唯一的数据源
const = useState;// 唯一的控制信号
// 不建第三个 state，直接算派生值
const filteredUsers = users.filter(user =>
user.name.includes
);

The key decision: {filteredUsers}` is **not** stored in state—it’s derived each render from two source states.

• If you stored it as its own state,you'd need to remember to call {setFilteredUsers}\` whenever eir source changes—missing one leads to UI drift.
• A derived value is declarative: “filteredUsers always equals users filtered by filterText”. No “forgot‑to‑update” scenario exists.

识别「伪状态」的三问法 🔍

1. This value can be computed from existing state/props?说起来， → If yes,compute it directly.
2. If this value changes。does anor piece of state have to change too?话说回来， → If yes,latter is likely derived.
3.  → If not。treat it as derived.

典型案例对比 🚦

// 三处相互依赖，容易出现不一致
const = useState;const = useState;// 可从 items 算
const = useState;// 可从 items 算

 ​
​
​
​

// 单一来源 + 派生
const =useState;// 派生值，不再使用额外 setX
const totalPrice= items.reduce=> sum+i.price,0);其实，const itemCount= items.length;

 .
.

 .