Hooks 与 React 19 — 状态、副作用、并发与表单Copy Anchor Link

这一章讲什么: 上一章说了「状态一变,React 把组件函数再调一遍」。 这一章解决随之而来的问题:函数每次重调,内部变量不就清零了吗?记忆从哪来? 答案是一整套 Hooks——而且 React 19 新增的钩子正在改掉「取数据靠 useEffect」的老习惯。 读完你能写出带状态、会取数、不卡输入框的组件,也知道无限循环是怎么自己造出来的。

1. 顶层全景:为什么要有 HooksCopy Anchor Link

形式化地说,函数组件就是一个接收参数、返回 JSX 的 JavaScript 函数——就这么简单¹。 复杂的是渲染循环:state 一变,函数被重调,JSX 重算,虚拟 DOM 比对后提交²。

问题来了:普通 JavaScript 函数每次被调用,都会开一个全新的作用域, 内部变量从头初始化。想让一个值「跨多次调用活下去」,靠函数自己做不到—— 所以 React 造了 Hooks:状态数据由 React 运行时单独托管, 虽然钩子在函数里面被调用,渲染之间它一点都不会丢³。

  组件函数第 1 次被调用 ──► 函数体的局部变量:死
        │                  Hook 里的状态:活(React 拿着)
  state 变化,函数第 2 次被调用 ──► 函数体重新执行,局部变量又死一遍
        │                          Hook 里的状态:接着上次的活
        ▼
  渲染循环

  图说:函数是临时工,每次上岗都是新人;Hook 是档案室,铁打的。

2. useState:一对返回值与一个铁律Copy Anchor Link

useState 的用法全书最常见:

const [label, setLabel] = useState("hello world");

右边调 Hook,给初始值;返回值是一个数组——第一个元素是状态值本身, 第二个是修改它的函数⁴。只调用 setLabel 才会让 React 安排一次更新; 光改变量没用——下次渲染,它还是从 React 的档案里取回旧值⁵。

配套的输入框模式叫受控组件(controlled component): <input value={label} onChange={onChange} />——输入框显示什么完全由 state 决定, 用户每敲一键,onChange 把新值写进 state,state 触发重渲染,输入框更新⁶。 绕一圈看着笨,但它让「界面 = state 的函数」这条等式不破。

props 是只读的。 子组件不许直接改 prop;想改,父组件传一个回调下来, 子组件调回调、父组件改自己的 state、React 用新 prop 重渲子组件—— 这个模式叫状态提升(lifting state up),是 React 单向数据流(数据只允许从父组件流向子组件)的地基⁷。 书里还有一个顺手的选择:不用 FC 泛型标注组件,只标参数类型——更短, 是现代的常见写法⁸。

列表渲染时,map 出来的每个元素要带一个 key 属性,值必须唯一: React 靠它在比对阶段认出「哪项变了、哪项新增、哪项删除」——没有它, 列表更新就没有效率可言⁹。

3. useEffect 与它的经典事故(本章主线例子)Copy Anchor Link

useEffect 管副作用:凡是要和 React 渲染管道之外的世界打交道的事—— API 调用、订阅、定时器、手动改 DOM¹⁰。它收两个参数:一个函数,一个 依赖数组;数组里的值(可以是 state、props、任何响应式值)一变,函数就执行¹¹。

主线例子:一个按 id 从 JSONPlaceholder(免费的测试 API)取用户列表的组件。 useEffect(() => { fetch(...).then(...) }, [id])——id 变了就重新取¹²。 取回数据后 setUsers(...):这个 state 不在依赖数组里,所以不会触发自己¹³。

现在把 users 也塞进依赖数组,看会发生什么:控制台里 「users updated」打到天荒地老。 原因一眼就能看穿: 依赖数组里有 users,而处理器里又更新 users——取数 → 更新 → 触发 → 再取数,无限循环¹⁴。真实代码里更阴的版本是:依赖数组里的某个对象/数组 每次渲染都是新引用,effect 每次都误判「变了」。书里给的铁律:

别更新依赖数组里也有的那个 state——那就是循环本身。 更新不在依赖数组里的 state(比如响应 fetch 去 setUsers)完全没问题¹³。

作者还补了一刀:在 useEffect 里取数据,越来越被认为是反模式—— React Query 这类库或框架级的 Server Components 做得更可靠; useEffect 的本职是和外部系统同步,纯粹的「触发一个外部动作」 (比如调 API 改数据库、不改本地 state)才是它最干净的用法¹⁵。

4. React 19 的答案:use + SuspenseCopy Anchor Link

use 是 React 19 的新 API——注意它其实不是 Hook(所以它敢待在 条件分支和循环里,Hook 不许)。它吃一个 Promise(或 Context), 效果约等于函数组件里的 await¹⁶。为什么需要它?函数组件不支持 async/await,Promise 之前只能塞在 useEffect 或事件处理器里; use 让组件函数运行到那一行时暂停(suspend), 等 Promise 有了结果再继续¹⁷。

配套的是 <Suspense>:use 在等的时候,React 展示离它最近的 Suspense 边界上声明的 fallback UI(比如一行 "Loading users ..."), 数据一到,换成真正的子组件¹⁸。原书的比喻很准: use 是「在函数组件里等 Promise」,Suspense 是「等一个将来才会渲染出来的 子组件」¹⁹。

主线例子的 React 19 重写:

// 父组件:制造一个稳定不变的 Promise
const fetchPromise = useMemo(() => fetchData(idToGet), [idToGet]);
// 子组件:use 它,渲染它
<Suspense fallback={<div>Loading users ...</div>}>
  <Fetcher fetchPromise={fetchPromise} />
</Suspense>

有一个坑原书特意点破:Promise 必须是同一个实例——所以用 useMemo 把 fetchData(idToGet) 包进 useMemo(把计算结果存起来复用的钩子);不然每次渲染都是新 Promise, use 会没完没了地暂停²⁰。刻意不 await 也是同一个原因: 我们要的就是那个「还没兑现的 Promise」,兑现交给 use 办²⁰。 相比 useEffect 版,没有依赖数组,没有「循环」陷阱,加载态是 JSX 里 明摆着的 fallback——异步从「小心伺候的副作用」变成了「声明出来的 UI 状态」。

5. 并发两钩:让渲染可以被打断Copy Anchor Link

React 18 引入并发渲染后,新增的两个钩子解决同一个痛:昂贵的渲染堵住 打字、点击这类高优先级交互²¹。

useDeferredValue 收一个值(通常是一片 state)。值变了, React 先用旧的值渲染一遍(界面立刻响应),再排一次后台渲染用新值; 后台这次可以被高优先级工作打断、稍后重来²²。原书的实验:3 万条消息 的列表按输入即时过滤——不加钩子时,敲四个字符卡一下; 把列表数据源换成 useDeferredValue(filteredMessages) 的返回值, 打字立刻跟手,列表稍后追上²³。

useTransition 收的不是值,是更新函数:

const [_isPending, startTransition] = useTransition();
startTransition(() => setSelectedItem(SelectedItem.Users));

startTransition 包起来的 state 更新是可中断的——200 个故意写慢 的列表项正在渲染时,用户点了另一个按钮,渲染立刻让路²⁴。 实验里同一个界面跑两遍:不包 startTransition,点「show message」 会被列表渲染吞掉;包了,消息立刻出现²⁵。

但有一个硬限制,原书用第二个实验把它钉死:useTransition 只能中断 直接从 startTransition 里调用的 state 更新。例子里把列表数据挪进 UsersLoader 自己的 state、用挂载时跑的 useEffect 填数据—— useEffect 在提交阶段之后运行,它的 setUsers 不在任何 transition 里, React 视它为紧急更新,整段渲染又变得不可中断²⁶。一句话: 管用的是「这次更新是不是在 startTransition 里发生的」,而不是 「这个 state 声明在哪儿」²⁷。

6. 表单三件套与乐观更新Copy Anchor Link

HTML 表单把相关字段聚在一起、一起提交²⁸。React 19 之前,表单意味着 给每个字段写受控组件样板;19 的三个钩子把样板消掉了:

useActionState 把一个异步 action 函数绑到 <form action={action}> 上, 返回 [formState, action, isPending]——表单最后的状态、提交函数、 是否还在提交中²⁹。字段的 <input> 不需要 value 和 onChange—— 提交时浏览器把表单包成 FormData 交给 action,样板全免; 提交按钮用 disabled={isPending} 防重复提交³⁰。

useFormStatus(来自 react-dom 包)解决「提交按钮想拆成独立组件, 但它怎么知道表单在不在提交中」——只要它是表单的子组件, 这个钩子就能替它拿到父表单的状态,props 都不用传³¹。

useOptimistic 是 Async Actions 系统的成员,效果是先显示未来的值: addOptimisticMessage 同步把新消息塞进界面(乐观地认为它终将成功), 然后 await 真正的异步写入;两者都包在一个 startTransition 里³²。 原书强调容易绕晕的一点:JSX 里渲染的是乐观那份 (optimisticMessages),不是真实数据源那份——乐观列表像一面 「知道未来的镜子」³³。消息列表里,点 add 文字立刻出现,2 秒后 后台的真实数据才跟上³⁴。适用边界作者也说了:只适用于你事先知道 结果长什么样的场景³³。

实验里值得记的两个数字Copy Anchor Link

原书的延迟实验给了两个可量化的锚点:DeferredData.ts 用 count = 30000 (三万条消息)故意制造渲染压力——书里明说,这个数不是神圣的,机器快就调大、 机器慢就调小,直到肉眼能感到卡顿为止;UserItem 里那个 while 循环空转 10 毫秒,模拟「一个写得不好、渲染偏慢的组件」。两个数字共同的教法是: 性能实验的关键不是数字本身,而是先把「慢」稳定地造出来,再谈优化—— 否则优化前后没有可比基线(useTransition 实验用 200 个这样的慢组件, 把「渲染吞掉点击」稳定复现,才有了对照)。

7. React Compiler:手工记忆化的终点Copy Anchor Link

React 19 配套的 React Compiler 是构建期工具,自动给应用代码做 记忆化(memoization):结果没变就缓存复用,省掉重复计算和内存分配³⁵。 它 2025 年 10 月发布 1.0 稳定版,在 Meta 的线上产品里打过仗³⁵。

它自动做的,正是以前开发者手工做的三件:

³⁶ Compiler 比手工做得更多:它在构建期分析数据流和可变性,能把记忆化插进 useMemo/useCallback 够不着的条件分支(比如 early return 之后)³⁷。 成效数字(书里引的):Meta 报 Quest Store 应用首载最快提升 12%、 交互快 2.5 倍以上;Wakelet 的最大内容绘制改善约 10%、下次绘制交互改善约 15%³⁸。 但它不是魔法:要求组件遵守 React 的规则(组件必须是 props/state 的 纯函数),分析不了的组件它会悄悄跳过³⁹。新项目模板(Expo/Vite/Next.js) 已可开箱启用;存量项目建议增量采用⁴⁰——所以手工三件套仍然要会读。

8. 作者的判断与证据Copy Anchor Link

• 「useEffect 取数据是反模式,React Query/Server Components 更可靠」 是明确的行业判断¹⁵;「useEffect 最干净的用法是不改本地 state 的外部动作」 同¹³。
• 「startTransition 只罩得住自己包住的更新」是机制性事实,有对照实验支撑²⁶²⁷。
• 「默认 const、能编译器就不手工记忆化」倾向明显;引用的性能数字来自 Meta/Wakelet 的官方报告,属转述³⁸。
• 对 FC 的取舍(不用)写明是「个人选择、现代常见」⁸。

9. 边界与局限Copy Anchor Link

• Rules of Hooks 没有展开:为什么 Hook 不能放进条件分支/循环(调用顺序即 档案索引)本书没讲机制,只通过 use「不是 Hook 所以可以」一句侧面带过。
• useEffect 的清理函数没演示:订阅、定时器的 return 清理——真实项目的高频 需求,本章例子只到「触发外部动作」为止。
• 并发钩子的适用门槛:useDeferredValue/useTransition 解决的是「重渲染 真的贵」的场景;对普通表单它们是用不上的,读者容易看了演示就到处套用。
• React Compiler 的采用状态变化快(2026 年中的口径),数字和「哪些模板 默认开启」请以当下官方文档为准(本节数字为书出版时点)。

判断(我们的,不是书里的): 本章最有教学价值的是把同一个取数需求 用 useEffect 和 use+Suspense 各写一遍——不是罗列新 API,而是让旧写法 的脆弱(依赖数组、循环陷阱、加载态散落在三处)在新写法的对照下自己现形。 「无限循环」实验(把 users 塞进依赖数组然后看它打到永远)尤其该留着: 那是每个 React 开发者真实踩过的坑。 如果错,会错在: 以取数为轴心的组织方式,会让读者低估事件驱动更新 (点按钮才取数)这条更主流的路径——本书最终应用(第 15 章)里大量 取数恰恰发生在 onClick 里,而不是 use/useEffect。

10. 可带走的Copy Anchor Link

1. Hooks 存在的原因是:函数组件每次重调都是新作用域,state 必须由 React 运行时托管。
2. useState 返回 [值, 修改函数];只调修改函数才触发更新。
3. 受控组件:value + onChange,输入框内容归 state 管。
4. props 只读;子要改、父传回调——状态提升。
5. 列表渲染必须给 key,否则比对阶段认不出谁是谁。
6. useEffect 铁律:别更新依赖数组里也有的 state;改外部系统比取数据更配它。
7. use + Suspense:组件函数里「等 Promise」,等的时候显示 fallback;Promise 要保持同一实例(useMemo)。
8. useDeferredValue 延迟值追赶;useTransition 让包住的更新可被打断——但只罩得住直接包进去的更新。
9. 表单:useActionState 免受控样板,useFormStatus 让子组件感知表单状态,useOptimistic 先显示未来。
10. React Compiler 自动做记忆化,但要求纯函数组件;手工三件套(useCallback/useMemo/memo)仍然要会读。

11. 原文地图Copy Anchor Link