React Hooks 深度与常见坑

Hooks 上手是真容易:写个 useState、再来个 useEffect,十有八九能跑。但"能跑"和"驾驭"之间隔着好几道坎。社区里大量 bug——输入框打到一半状态重置、useEffect 死循环刷接口、点击拿到的是旧值、lint 报依赖警告索性一行注释打发——根上都是同一个问题:只把 Hooks 当 API 记,没建立它背后的心智模型。

Hooks 不是生命周期,也不是魔法。它背后的机制朴素到只有两件事:每次渲染,组件函数都从头到尾重新执行一遍;每次执行捕获的变量,构成那一帧的闭包。 把这两条吃透,后面所有"为什么这里拿到旧值""为什么 effect 跑了两次""为什么 lint 冲我吼"都会有清晰答案。本文不讲 API 签名,讲的是心智模型、四大经典坑、useRef 的真实定位、自定义 Hook 的抽取原则,以及"useEffect 不是生命周期"这件事到底意味着什么。

一、心智模型:函数每帧重新执行 + 闭包捕获

类组件的时代,this.state 是一个持续存在的对象,this 指向同一个实例,你在任何时刻读 this.state.count 拿到的都是"当前最新值"。Hooks 把这个模型彻底推翻了。

函数组件里没有一个"持续存在的实例"。每次渲染,React 调用你的组件函数,从第一行执行到最后一行,产出一棵新的元素树,然后这个函数的作用域就结束了。下次渲染,React 再调用一次这个函数——一个新的、全新的作用域。这意味着:

function Counter() {
  const [count, setCount] = useState(0);
  // 这里的 count,是"这一帧渲染时"的快照,不是某个持续更新的活值
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

count 不是"一个会变的变量",而是**"这一次渲染时拍下的状态照片"**。点 3 次按钮后第 4 次渲染时,这一帧的 count 是 3,整棵组件树里所有引用 count 的地方,在这一帧里都是 3。下一次渲染,是新的一次函数调用,新闭包里的 count 是 4。

这个"每次渲染一个新闭包"的模型,是理解后面所有坑的基石。闭包捕获的不是"变量的最新值",而是"这次渲染时的值"。 当你在 setTimeout、事件回调、useEffect 里读一个外层变量,你读到的永远是那次渲染拍下的照片,不是"现在"的值——这就是后面 stale closure 的根。

二、useState / useReducer:批处理与函数式更新

useState 看起来简单,但两个细节没吃透就会踩坑:批处理和函数式更新。

React 18 之后,所有状态更新默认批处理——哪怕你在 setTimeout、Promise 回调里连续调多次 setter,React 也会把它们合并成一次渲染。所以连续三次 setCount(c + 1) 只会 +1,因为三次读到的 c 都是同一帧的旧值:

// 反例:三次 set 都基于同一帧的 count,最终只 +1
const handleTripleBad = () => {
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
};

// 正解:函数式更新,每次基于"上一次的最新值"累加
const handleTripleGood = () => {
  setCount((c) => c + 1);
  setCount((c) => c + 1);
  setCount((c) => c + 1);
};

判断标准很简单:新状态依赖旧状态 → 用函数式更新 setX(prev => ...)。 这条规则也顺带解决了 stale closure 的一类场景——你不需要"读到最新的 count",只需要把"怎么从上一个变到下一个"告诉 React。

状态一旦复杂到三四个字段互相联动(典型:带 loading/error/data 的请求状态、多步表单),就别再堆 useState 了,上 useReducer——把状态变迁逻辑收敛到一个 reducer 里,比散落一地的 setter 清晰得多,也更好测。

三、useEffect 的真相:它不是生命周期,是"声明同步副作用"

这是 Hooks 里被误解最深的一个。很多人把 useEffect 当成类组件 componentDidMount + componentDidUpdate + componentWillUnmount 的合体,于是在里面写"组件加载时调一次接口""组件卸载时清定时器",再拍一个空依赖数组 [] 了事。

这个心智模型是错的,而且会让你写出依赖遗漏的 bug。

正确的模型是:useEffect 是"声明一次同步副作用"。你告诉 React:"我希望这个副作用,跟这些依赖保持同步——只要 deps 里任何一个变了,就重新跑一次,把上一次的清理掉。" 依赖数组不是"什么时候触发"的开关,而是**"这个副作用关心哪些值"的诚实清单**。

• useEffect(fn, [a, b]):副作用依赖 a、b,它俩一变就重新同步(清旧的、跑新的)。
• useEffect(fn, []):副作用什么都不依赖,所以只在挂载时同步一次。
• 不传数组:每次渲染都重新同步——几乎从不需要。

空数组不等于"mount"——它只是"这个 effect 声明了自己不依赖任何值"的特殊情况。如果你在里面读了一个外层的 props.id,但又没把它放进依赖,那就是在撒谎:effect 用到了 id,却告诉 React"我跟 id 无关"。React 会一直用第一次的那个 id,后续 id 变了也不重新拉——经典的 stale 数据 bug。正确写法是把用到的值都诚实地写进依赖,让 React 替你重新同步。

四、四大经典坑:每一坑都有根因

坑 1:stale closure(拿到旧值)

// 反例:setInterval 的回调永远捕获第一次的 count,永远显示 0
function Timer() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    const id = setInterval(() => setCount(count + 1), 1000); // count 永远是 0
    return () => clearInterval(id);
  }, []); // 空依赖 → effect 只跑一次 → 闭包锁死在 count=0 那一帧
  return <span>{count}</span>;
}

// 正解 1:函数式更新,不读外层 count
useEffect(() => {
  const id = setInterval(() => setCount((c) => c + 1), 1000);
  return () => clearInterval(id);
}, []);

// 正解 2:把 count 放进依赖,让它重新同步(但 setInterval 会被反复重建)

记住:闭包里的变量是"那一帧的照片"。要么用函数式更新绕开对外层值的依赖,要么把值诚实写进 deps。

坑 2:依赖数组遗漏

把 eslint-plugin-react-hooks 的 react-hooks/exhaustive-deps 规则打开,并设为 error。它警告的不是"代码风格",而是"你这里有个真实的 stale closure 风险"。看到警告去修依赖,而不是用 // eslint-disable-next-line 把它按死——按掉的每一次,都是一颗未来会炸的雷。如果你"加了依赖就会死循环",那说明坑 3 已经在等你了,根因是 effect 的逻辑本身有问题。

坑 3:无限循环

// 反例 1:依赖里塞了每次都是新引用的对象/数组
useEffect(() => {
  fetch("/api").then(setData);
}, [data]); // data 是 state,setData 后 data 变 → effect 又跑 → 又 setData → 死循环

// 反例 2:把对象内联当依赖
useEffect(() => {
  doSomething({ id });
}, [{ id }]); // 每次渲染都是新对象,浅比较必不相等 → 每帧都跑

无限循环几乎都是同一个模式:effect 里 setState,且依赖项又被这个 state(或每次新建的引用)驱动。 解法是分清"这个 effect 真正依赖什么"——是依赖某个原始值(id、query),就只放原始值;是依赖一个派生对象,就把它的计算结果用 useMemo 稳住,或者干脆把对象按字段展开成原始依赖。[] 救不了你,它只是把循环换成 stale。

坑 4:在条件/循环里调 Hook

// 反例:条件调用 Hook,违反 Rules of Hooks
if (ready) {
  const [data, setData] = useState(null); // 报错:Hook 顺序被打乱
}

Hooks 靠调用顺序把状态对上号——React 内部用一个链表按顺序存每次渲染的 hook 状态。一旦你把 hook 放进条件/循环,顺序在不同渲染间会变,React 立刻报错。规则铁硬:Hook 只能在组件顶层调用。 想按条件启用?把条件放进 hook 内部,而不是包住 hook:

// 正解:hook 总在顶层调,条件塞进 hook 的实现里
const data = useFetch(id, { enabled: ready });

五、useRef:被低估的"盒子"

useRef 经常被简化成"存 DOM 节点用的"。这没错,但它真正的定位更有用:一个不触发重渲染的可变盒子。它和 useState 的关键区别是——改 ref.current 不会让组件重新渲染,而且 ref 对象本身的引用在组件整个生命周期里永远不变。

这两点合起来,useRef 能干两件 useState 干不了的事:

1. 访问 DOM: <div ref={el => (boxRef.current = el)} />,经典用法。
2. 跨渲染保存一个"最新值"的可变引用——这是破 stale closure 的另一把刀,尤其适合"事件回调里要读到最新的 props/state,但又不想让它触发重新订阅"的场景:

// 用 ref 保存最新的 props,让一个"只订阅一次"的 effect 里也能拿到最新值
function SearchBox({ query }: { query: string }) {
  const queryRef = useRef(query);
  useEffect(() => { queryRef.current = query; }); // 每次渲染同步最新值

  useEffect(() => {
    // 只在挂载时订阅一次,但回调里读到的永远是最新 query
    const handler = () => console.log("current query:", queryRef.current);
    window.addEventListener("keydown", handler);
    return () => window.removeEventListener("keydown", handler);
  }, []);
  return <input value={query} /* ... */ />;
}

这是处理"我不想因为依赖变化而重新订阅、但又需要最新值"的标准模式——也被称为 useEvent / useLatest 的底层实现思路。别滥用 ref 替代 state:只要这个值的变化需要驱动 UI,就该用 useState,ref 改了 UI 不会刷新。

六、useMemo / useCallback:多数时候你不需要

社区最大的误区之一:把 useMemo/useCallback 当默认写法。真相是——它们本身有成本(每次渲染要做 deps 浅比较 + 占内存缓存),只有"省下的开销 > 引入的开销"才划算。

• useMemo:只在那个计算真的贵(大列表 sort/filter、复杂格式化)且会反复跑时才有意义。
• useCallback:只在你要把这个函数传给一个被 memo 包裹且确实因为引用变化而重渲染的子组件时才需要。

绝大多数被 useMemo 包的值,不包也快得很。这个问题在《React 性能优化实战》里讲得很细,这里只给一条铁律:凭感觉加 memo 是错的,先量(Profiler)再决定。 当你想加 useCallback 的原因是"听说加了性能好",而不是"量出来这里 props 不稳定导致子组件白渲染",就别加。

七、自定义 Hook:抽取状态逻辑,组合优于继承

Hooks 之前,React 复用逻辑只能靠 HOC 和 render props——层层嵌套、props 来源混乱。Hooks 给了一条干净的路:把一段状态+副作用逻辑抽成一个函数,返回需要的值和操作。 抽取原则三条:

1. 按"一件事"抽,不按"一行代码"抽。useDebounce、useFetch、useLocalStorage、useMediaQuery——名字能说清干什么,边界就清楚。
2. 返回值要克制:[value, setValue] 或一个对象,字段稳定、含义清晰。
3. 组合优于继承:一个自定义 Hook 内部可以调用别的 Hook,useFetch 里可以套 useState/useEffect/useAbortController,组合出复杂能力。

// 一个实用的 useDebounce:把频繁变化的值延迟成"停止变化 N ms 后的值"
function useDebounce<T>(value: T, delay: number): T {
  const [debounced, setDebounced] = useState(value);
  useEffect(() => {
    const id = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(id); // 每次 value 变都清掉旧定时器,避免抖动
  }, [value, delay]);
  return debounced;
}

// 使用:输入框防抖搜索,干净到像在写配置
const debouncedQuery = useDebounce(query, 300);
useEffect(() => {
  if (debouncedQuery) search(debouncedQuery);
}, [debouncedQuery]);

判断一段逻辑该不该抽成 Hook,标准是**"它会在第二个地方复用吗"**。会 → 抽;不会 → 别为了抽而抽,留在组件里更直白。

八、调试与防御:devtools + 依赖检查

防御手段是标配两件套:

• eslint-plugin-react-hooks,exhaustive-deps 设为 error——把 stale closure 扼杀在编辑器里,而不是上线后用户帮你发现。
• React DevTools 的 Profiler + Components 面板:Components 面板能直接看每个组件当前 hooks 的值;Profiler 录制一次交互,能看到"哪次渲染、为什么渲染、渲染了多久"。effect 跑了几次、每次是什么触发的,一目了然。

加一条经验:在开发环境看到 effect 跑了两次,别慌——这是 React 18+ Strict Mode 的故意行为(挂载→卸载→再挂载),用来暴露你的 effect 清理函数写得对不对。如果你的 effect 清理没写对(订阅没取消、定时器没清、监听没移除),Strict Mode 会替你在开发期炸出来,上线前修掉就行,而不是让用户在生产环境里遭受内存泄漏。

小结

1. Hooks 的心智模型只有两条:每次渲染组件函数都从头执行一遍;每次执行捕获的变量构成那一帧的闭包。count 不是"活值",是"这次渲染的照片"。所有 stale closure 都源于没认清"闭包抓的是旧照片"。
2. useEffect 不是生命周期,是"声明一次同步副作用"。依赖数组是你"这个副作用关心哪些值"的诚实清单,空数组只是"什么都不依赖"的特例而非 mount 的语法糖。把用到的值都写进依赖,别靠 // eslint-disable 蒙混过关。
3. 四大经典坑各有解药:stale closure 用函数式更新或 ref 最新值;依赖遗漏靠 exhaustive-deps 兜底;无限循环分清"真正依赖的原始值" vs "每次新建的引用";Hook 只能在组件顶层调用,条件塞进实现而不是包住调用。
4. useRef 是"不触发重渲染的可变盒子":除了访问 DOM,更是"跨渲染持有最新值、又不引发重订阅"的关键工具。useMemo/useCallback 是优化手段不是默认写法,先量再决定要不要加。
5. 自定义 Hook 是复用状态逻辑的干净方式(useDebounce/useFetch/useLocalStorage),按"一件事"抽,组合优于继承。配齐 react-hooks/exhaustive-deps + DevTools,把 bug 扼杀在开发期。

金句:Hooks 不是生命周期,是"每帧一个新闭包 + 一份依赖清单"。 想清楚"这次渲染我手里的值是哪一帧的照片""这个 effect 到底依赖什么",剩下的坑自己就塌了。