許多開(kāi)發(fā)者都遇到過(guò)這樣的困惑：在調(diào)用 setState（如 setCount(1)）后緊接著 console.log(count)，輸出的仍是舊值。這種現(xiàn)象并非個(gè)例，而是 React 渲染與調(diào)度機(jī)制的必然結(jié)果。

本文將用清晰的流程與貼近日常的比喻，說(shuō)明 為什么 useState 不會(huì)“即時(shí)”生效、React 的渲染如何運(yùn)作，以及該如何正確地響應(yīng)與使用狀態(tài)更新。

useState 是什么？

useState 是給函數(shù)組件添加狀態(tài)的 Hook，它返回“當(dāng)前值”和“更新該值的函數(shù)”：

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

表面上很簡(jiǎn)單，但一旦出現(xiàn)如下寫法，疑問(wèn)就來(lái)了：

setCount(1);
console.log(count); // 為什么還是 0？

useState 是“異步”嗎？

嚴(yán)格來(lái)講，useState不是像 Promise 那樣的異步 API；但更新不會(huì)立刻應(yīng)用?？梢园?nbsp;setState 理解為向 React 發(fā)出的請(qǐng)求：

“請(qǐng)把這個(gè)值改成 X，等合適的時(shí)機(jī)再更新 UI?！?/p>

React 會(huì)在下一次渲染周期里應(yīng)用更新，而不是在當(dāng)前函數(shù)調(diào)用過(guò)程中立刻改寫變量。因此，在 setState 后立刻讀取，看到的仍是更新前的值。

幕后發(fā)生了什么？

React 為了性能，會(huì)對(duì)更新進(jìn)行批處理（batching）。當(dāng)調(diào)用 setCount(1) 時(shí)，大致流程如下：

1. 記錄更新請(qǐng)求（把“把 count 改為 1”加入更新隊(duì)列）；
2. 等待當(dāng)前函數(shù)執(zhí)行完畢（確保一次事件中的多次更新可以合并）；
3. 觸發(fā)重新渲染（以新?tīng)顟B(tài)重新執(zhí)行組件函數(shù)，生成新 UI）。

 在觸發(fā)新一輪渲染之前，組件函數(shù)內(nèi)部“看見(jiàn)”的仍是舊狀態(tài)。

為何 setState 后立刻 console.log 不奏效？

const [name, setName] = useState('John');

const handleClick = () => {
  setName('Jane');
  console.log(name); // 輸出 "John"，而不是 "Jane"
};

原因很簡(jiǎn)單：console.log 發(fā)生在本次函數(shù)執(zhí)行之內(nèi)，而狀態(tài)變更會(huì)在下一次渲染時(shí)生效。

正確寫法：函數(shù)式更新（functional update）

當(dāng)新?tīng)顟B(tài)依賴舊狀態(tài)時(shí)，使用函數(shù)式更新可以確保拿到最新的基準(zhǔn)值，即便在批處理場(chǎng)景中也安全可靠：

setCount(prev => {
  const next = prev + 1;
  console.log('更新過(guò)程中的值：', next);
  return next;
});

這樣 React 會(huì)把 prev 設(shè)為真正的最新舊值，避免競(jìng)爭(zhēng)條件。

想在“更新后”做事？用 useEffect

需要在狀態(tài)變更并完成重新渲染后執(zhí)行副作用邏輯，使用 useEffect 訂閱目標(biāo)狀態(tài)：

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

useEffect(() => {
  console.log('count 已更新為：', count);
}, [count]);

當(dāng) count 引發(fā)組件完成一次新的渲染后，上述副作用才會(huì)運(yùn)行。

生活類比：點(diǎn)咖啡

• 你：“來(lái)一杯卡布奇諾?！保╯etState）
• 咖啡師：“收到！”（React 記錄更新，安排下一輪渲染）
• 你立刻看柜臺(tái)：咖啡還沒(méi)出現(xiàn)（console.log 仍是舊值）
• 片刻后：咖啡端上來(lái)（完成渲染，UI 與狀態(tài)同步）

setState 像是下單：并不會(huì)立刻得到咖啡，但它已經(jīng)在路上。

實(shí)戰(zhàn)要點(diǎn)與易錯(cuò)點(diǎn)

• 同一事件中的多次 setState 會(huì)被批處理避免在一次點(diǎn)擊中多次依賴“立刻更新”；要么函數(shù)式更新，要么把后續(xù)邏輯放到 **useEffect**。
• 日志位置要講究想要看到更新后的值，不要在 setState 之后立刻 console.log，而應(yīng)放在 useEffect 中。
• 新值依賴舊值一律用函數(shù)式更新：setX(prev => compute(prev))。
• 副作用不要寫在渲染邏輯里組件函數(shù)應(yīng)保持純粹；副作用（例如請(qǐng)求、訂閱、DOM 操作）放進(jìn) **useEffect**。
• 理解渲染是“重跑函數(shù)”每次渲染都會(huì)重新執(zhí)行組件函數(shù)，useState 返回的值是當(dāng)次渲染的快照，而非可隨時(shí)改變的變量。

小結(jié)

• useState 的更新不會(huì)在當(dāng)前函數(shù)內(nèi)立刻生效；
• React 會(huì)批處理更新并在下一次渲染中應(yīng)用；
• 需要基于舊值更新，使用函數(shù)式更新；
• 想在更新完成后做事，用 useEffect 訂閱；
• 把 setState 當(dāng)作“下單”，新 UI 會(huì)在下一輪渲染“端上來(lái)”。

掌握這些機(jī)制，就能寫出更可預(yù)測(cè)、少坑位的 React 代碼。下次再遇到“為什么狀態(tài)沒(méi)更新”的困惑時(shí)，不妨回想：更新已下單，正在路上。