React Hooks四大核心概念：从原理到实战一次讲透

一个特别常见的场景新项目定了 React 函数组件 Hooks结果第一天就有人问——函数里没有 this、没有 setState那些业务状态到底往哪儿放为什么 useEffect 里的依赖数组一写多就疯狂重渲染又为什么某些数据明明已经存在 state 里界面却死活不更新这些问题表面上是 API 用法不对根子上其实是没有打通 React Hooks 背后四个核心概念数据驱动、副作用、状态传递、状态派生。这篇文章就围绕这四个概念从原理讲到实战从正向用法讲到踩坑经验一次说透。适合正在学 Hooks、准备从 class 组件迁移的人也适合已经写了一阵 Hooks 但总觉得哪里不对的工程师。1. 函数组件凭什么拥有 stateHooks 要解决的 class 痛点React 16.8 之前函数组件通常被叫做“无状态组件”你给它 props它返回 JSX除此之外什么都干不了。这是 React 早期有意设计的“分工”——有状态、有生命周期的逻辑必须写在 class 组件里于是社区里长期存在一套认知能写 class 尽量写 class函数组件只配做最轻的展示层。class 组件的问题不只是“字多”。我最早写 React 时最头疼的是 this。构造器里初始化 state然后每个处理函数都要考虑绑定问题忘了 bind 就会直接报错后来大家习惯用箭头函数类属性但那只是绕开 this 的一种语法糖并没有从本质上简化心智模型。第二个痛点是生命周期把相关逻辑切碎了。一个订阅类功能得在 componentDidMount 里建立订阅、在 componentWillUnmount 里取消订阅如果订阅参数还依赖某个 props 变化又得在 componentDidUpdate 里重新建一遍。同一件事被摊到三个生命周期方法里代码一会儿上一会儿下看代码的人很容易晕也特别容易漏掉清理逻辑。第三个痛点是逻辑复用。早期社区为了解决多个组件共享同一段有状态逻辑发明了高阶组件和 render props。高阶组件本质是“用一个函数包一层组件”多层包下来就变成“包装地狱”render props 则让 JSX 里出现大量嵌套回调。逻辑复用从“如何把状态逻辑抽出来”变成了“如何给组件再包一层”的脑力游戏。Hooks 的设计思路是把问题倒过来不再用生命周期和类实例去组织逻辑而是用原语去组织。useState 管状态useEffect 管副作用useRef 管可变引用useContext 管跨层级传值。有了这些原语函数组件才名正言顺地拥有 state逻辑复用也退化成最简单的“抽一个函数”。想理解 Hooks 为什么坚持“调用顺序必须稳定”得先明白底层实现。React 在组件对应的 fiber 节点上维护一个 hook 链表每次渲染函数组件时React 按照函数体内 hook 的调用顺序从链表里取出对应的状态记录。第一次渲染时创建节点、串成链表后续每次渲染都按同样顺序回来“认领”自己的状态。如果某个 hook 被塞进 if 里顺序一断后面的 hook 全部错位。所以你看到官方要求“只在顶层调用 Hooks”那不是风格建议是机制约束。名字以 use 开头也不是语法要求运行时没有强制力。但 eslint-plugin-react-hooks 正是靠这个前缀识别哪些函数内部调用了 hook然后静态检查调用顺序和依赖完整性。所以封装自定义 Hook 一定要遵守 use 前缀这不是仪式感是给工具递钥匙。2. 数据驱动UI 是状态的函数不是 DOM 操作脚本很多从 jQuery 时代过来的开发者最初最不适应 React 的一点就是你是在“写界面”而不是“改界面”。jQuery 的模型是“数据在 DOM 里你找到节点然后修改它”React 的模型是“数据在 state 里你修改 state然后让 React 根据最新 state 重新渲染 DOM”。“数据驱动”四个字听上去抽象落到代码里只有一句话只负责描述状态是什么样不负责描述状态怎么变。2.1 一条核心心智模型改状态而不是改界面比如受控组件。input 的 value 直接绑到 useState 返回的 stateonChange 里只更新 state。你永远不需要 document.getElementById(input).value xxx。界面的每次变化都由渲染过程保证所以调试受控组件时界面上每一个字段都能倒推到 state思路非常干净。心智模型转变后你会发现很多习惯要改。过去做“点击按钮让列表出现一项”会想找到 ul 节点append 一个 li。现在只想点击按钮setList([...list, newItem])。DOM 怎么变是 React 的职责你要处理的只有数据。2.2 useState 的使用细节不可变更新、函数式更新、惰性初始化useState 有三个实现层面的细节直接影响代码正确性值得单独记。第一不可变更新。如果 state 是对象或数组原地修改后再 setStateReact 会用 Object.is 比较前后引用发现引用没变不会触发渲染。比如 items.push(item) 之后再 setItems(items)界面毫无反应这是新手最容易撞的墙。正确做法是 [...items, item] 或 items.concat(item)让引用变化。更深层原因和并发渲染有关React 18 开启并发特性后渲染过程可能被中断、恢复如果大家共享的是可变对象不同时间片拿到的快照会互相污染。所以不可变更新不是“React 的怪癖”它是整个设计的前提。嫌 spread 手写麻烦可以引入 Immer写法上像原地修改实际上生成新引用。第二函数式更新。setCount(count 1) 在单次事件里连续调用三次最终只会加一因为这次渲染闭包捕获的 count 还是旧值三次 set 的都是旧值 1。如果你期望基于最新值连续计算得写 setCount(c c 1)。函数式更新的参数是队列里的最新值React 会按顺序把函数排队最后得到正确结果。React 18 自动批处理时代这个坑比过去更容易踩因为 Promise、setTimeout 回调里也会批量更新不再局限于事件处理器。第三惰性初始化。useState(() expensiveRead()) 比 useState(expensiveRead()) 更值得推荐。前者只在首次渲染时执行一次后者每次渲染都会执行尽管返回值没用上。初始值需要读 localStorage、indexedDB 或做复杂计算时惰性初始化是唯一正确选择。2.3 实战受控组件与筛选列表看一个典型的数据驱动例子关键字筛选列表function FilterList({ items }) { const [keyword, setKeyword] useState(); const filtered items.filter(item item.name.toLowerCase().includes(keyword.toLowerCase()) ); return ( input value{keyword} onChange{(e) setKeyword(e.target.value)} placeholder搜索名称 / ul {filtered.map(item li key{item.id}{item.name}/li)} /ul / ); }这个组件里keyword 是真正的 state因为它是用户输入的原生数据filtered 是派生值每次渲染由 items 和 keyword 计算出来。注意我们没有额外设置 filteredList 这个 state也不会因为 keyword 变了就手动维护它。这个意识极其重要也是后面“状态派生”部分的伏笔。3. 副作用useEffect 是把“现实世界”同步进来的通道函数组件每次渲染理论上应该是“纯”的同样的 props 和 state返回同样的 UI过程中不碰外部世界。但真实应用没办法这么干净要发网络请求、要监听鼠标键盘、要写 localStorage、要改 document.title。这些操作统称副作用。如果在函数体内部直接做副作用会有问题React 可能因为并发渲染多次调用组件函数也可能在 StrictMode 下故意执行两次来暴露问题。比如“发请求”这种操作跑在函数体里同一渲染可能被重复触发多次。useEffect 的意义就在于给副作用一个明确阶段渲染提交到屏幕之后、浏览器完成绘制之后再异步执行。在这个时间点DOM 稳定你读 DOM、操作外部库都安全。3.1 依赖数组是 useEffect 的灵魂依赖数组的语义是依赖变化且组件完成渲染提交后重新执行 effect。它没那么玄一张表就能看懂写法执行时机什么时候用useEffect(fn)每次渲染后都执行基本不用除非想做“每次渲染都埋点”useEffect(fn, [])只在首次挂载后执行一次初始化事件监听、首次拉数据useEffect(fn, [a, b])a 或 b 变化时执行依赖 props/state 变化的副作用不传依赖数组时每次渲染都跑实战里很少用因为大部分 effect 不需要这么频繁。空数组表示“只跑一次”经常被误解成“组件只需要初始化一次”。严格模式下开发环境会执行两次这个我在最后一章会专门说。3.2 清理函数不只是卸载时才执行effect 的返回值如果是函数那么在下一次 effect 执行之前React 会先执行这个清理函数组件卸载时也会执行。很多人以为清理函数只对应 componentWillUnmount于是写监听器时只加了一次 listener依赖更新后没有清理结果同一个监听器被重复添加回调执行多次。正确的订阅写法useEffect(() { const handler (e) setPosition({ x: e.clientX, y: e.clientY }); window.addEventListener(mousemove, handler); return () { window.removeEventListener(mousemove, handler); }; }, []);依赖数组是 [] 时这个 effect 只挂一次监听。如果依赖数组里有 props比如要监听当前 userId 的聊天那么 userId 变化时效果是先清理上一个 user 的监听再挂上新的。“每次 effect 前先清理”的本质是让副作用始终和最新渲染对齐避免旧状态残留。3.3 请求竞态一个必须处理的真实问题异步请求中最容易出现响应顺序不一致。连续快速切换页码page1 的响应可能比 page2 晚到后到的旧数据反而覆盖了最新数据。最常见解法是“ignore flag 清理函数”useEffect(() { let ignore false; setLoading(true); fetch(/api/products?page${page}) .then(res res.json()) .then(data { if (!ignore) { setList(data); setLoading(false); } }); return () { ignore true; }; }, [page]);当 page 变化触发下一次 effect 前上一次的清理函数把 ignore 置为 true于是上一次请求即使回来也不会执行 setList。想用 AbortController 直接取消请求也可以但 ignore flag 是最轻量、代码最清晰的方案。我的经验是简单页面用它足够真有大量并发请求再引入更重的取消机制。3.4 useEffect 与 useLayoutEffect 怎么选useEffect 在浏览器绘制完成后异步执行useLayoutEffect 在绘制之前同步执行。大多数场景用 useEffect 就行。但如果你需要读取布局、测量尺寸再同步修改 DOM比如弹层定位、滚动容器高度用 useLayoutEffect 能避免用户看到一帧“位置不对”的闪烁。一个实用判断如果 useEffect 里要同步读 DOM 尺寸并改样式改成 useLayoutEffect。需要服务端渲染兼容时可以封装成 isomorphic 版本服务端走 useEffect客户端走 useLayoutEffect。日常业务里遇到 useLayoutEffect 的频率不高但这种“绘制前 vs 绘制后”的差别值得记住。4. 状态传递props 逐层下发、Context 跨层共享与状态提升React 的状态传递有一个基本原则数据流向单向。父组件通过 props 把 state 交给子组件子组件想改数据不直接改而是调用父组件传来的回调回调在父组件里执行 setState再触发重新渲染。这样做的好处是数据变化路径唯一且显式你能顺着代码查出“这个值是在哪里被改的”。4.1 单向数据流和状态提升为什么是基础当多个子组件需要共享同一个状态时正确操作是“状态提升”把 state 放到它们最近的共同父组件里子组件通过 props 拿值和回调。比如一个页面有搜索框和列表keyword 虽然只在搜索框里输入但列表需要它做筛选于是把 keyword 提升到父组件搜索框拿 value 和 onChange列表拿 keyword。如果两个子组件之间没有共同父组件就再包一层。这个模式是 React 应用最容易推理的状态流动方式也是大多数“组件之间怎么通信”问题的标准答案。4.2 prop drilling 的坏味道与 Context 的引入状态提升用多了也有坏味道就是 prop drilling组件 A 要顺着很深的一棵组件树把某个 props 传给最底部的 D中间的 B、C 和这个数据毫无关系只是为了传话。这种代码改起来让人崩溃改一个属性名整条链路都要同步修改。Context 解决的不是“数据共享”问题而是“跨层级传递的成本”。创建 createContextProvider 的 value 承载数据后代组件用 useContext 直接读取。但 useContext 有一个经典性能坑Provider 每次渲染时如果 value 是新对象所有消费该 Context 的组件都会重新渲染哪怕它们只关心其中一个字段。const ThemeContext createContext(null); function ThemeProvider({ children }) { const [theme, setTheme] useState(light); const toggleTheme useCallback(() { setTheme(t (t light ? dark : light)); }, []); const value useMemo(() ({ theme, toggleTheme }), [theme]); return ThemeContext.Provider value{value}{children}/ThemeContext.Provider; }value 用 useMemo 固定引用后theme 不变时value 引用也不变consumer 不会被无关渲染波及。这属于“状态传递”里特别容易忽略的一层但往往是性能问题的源头。4.3 useReducer Context轻量级状态管理组合当同一份状态被多个组件共享、且更新逻辑比较复杂时我通常用 useReducer Context 代替 useState 加一堆散装回调。const CartContext createContext(null); function cartReducer(state, action) { switch (action.type) { case add: return { ...state, items: [...state.items, action.product] }; case remove: return { ...state, items: state.items.filter(p p.id ! action.id) }; case clear: return { ...state, items: [] }; default: return state; } } function CartProvider({ children }) { const [state, dispatch] useReducer(cartReducer, { items: [] }); const value useMemo(() ({ state, dispatch }), [state]); return CartContext.Provider value{value}{children}/CartContext.Provider; }组件只需要 useContext(CartContext) 拿到 dispatch然后 dispatch({ type: add, product })它完全不关心 items 内部怎么变。更新逻辑全部收进 reducer还能单独做单元测试。对大多数中小型应用这套组合已经足够真不用急着引全局状态库。说到状态传递还有一个和引用稳定性相关的问题。如果父组件每次渲染都生成新的函数或对象即使给子组件包了 React.memo浅比较 props 时因为引用每次都不同memo 也会失效。所以想让 memo 子组件稳定父组件传入的函数要用 useCallback传入的对象要用 useMemo。反过来也提醒我们优先把状态放在真正使用它的层级不要让一小撮组件的便利把一大片组件都卷进频繁变化的 state 里。5. 状态派生能算出来的值不要用 useState 去存我 Code Review 时最常提的一句建议是“这个 state 是多余的直接算就好了。”派生状态指的是那些可以由现有 props 或 state 计算出来的值比如列表筛选结果、总价、格式化文本、按钮禁用状态。它们不是用户输入的原始数据只是展示层的计算结果。5.1 派生状态的反模式手动同步副本把派生值单独存成 state 的问题在于多了一个需要同步的副本。更新逻辑一旦漏一步原始数据变了副本没变界面上就会出现“明明数据改了但显示不对”的诡异现象。class 时代最典型的就是 getDerivedStateFromPropsReact 官方甚至专门写文章劝大家“你可能不需要派生状态”。Hooks 时代对应的反模式是在 useEffect 里 setState 去同步某个 props 的变化。绝大多数情况下这个 effect 根本不需要直接在渲染时计算就行。在 render 里 setState 更是明确的 bug会引起死循环。前面 FilterList 的 filtered 就是一个完美例子直接计算不存 state。把这个原则推广开你会发现很多让人困惑的状态同步问题都消失了。5.2 useMemo 的真正价值和适用范围如果要处理的数据量很大每次渲染直接 filter、sort 可能有点重这时用 useMemo 缓存const filtered useMemo( () items.filter(item item.name.includes(keyword)), [items, keyword] );useMemo 真正值得用的场景有三类计算本身比较重大量数据处理、复杂递归、重格式化计算结果是对象/数组作为 props 传给 memo 子组件或作为依赖传给 useEffect需要引用稳定组件渲染频率高计算明显拖慢渲染。除此之外别盲目给每个计算都套 useMemo。它本身要创建闭包、做依赖比较对于纯加法、字符串拼接这种轻计算反而可能更慢。还要记住useMemo 不是语义缓存React 可以在组件卸载、内存紧张时丢弃缓存重新计算。不要编写依赖“这个值一定只算一次”的业务逻辑。5.3 React 18 的新思路useDeferredValue 与 useIdReact 18 给“派生状态”带来一个新工具 useDeferredValue典型场景是输入框驱动一个非常昂贵的列表渲染。直接按输入更新页面会顿卡防抖可以缓解但防抖本质是“晚一点算”而 useDeferredValue 是“低优先级算”让输入框立即响应列表渲染在后台可中断function SearchPage() { const [keyword, setKeyword] useState(); const deferredKeyword useDeferredValue(keyword); const results useMemo( () search(deferredKeyword), [deferredKeyword] ); return ( input value{keyword} onChange{e setKeyword(e.target.value)} / Results list{results} / / ); }useDeferredValue 不适合替代所有 useMemo但它刷新了我对“派生值要不要立即算”的理解当派生计算成为卡顿源头时把输入框和昂贵渲染之间的优先级拆开用户会明显觉得“手跟得上”。另外useId 用来生成稳定的唯一 id适合 label 的 htmlFor、aria 关联。它也是派生值不是业务状态千万别存进 state。6. 自定义 Hooks把四类问题收敛成可复用逻辑自定义 Hook 是 React Hooks 模式里最被低估的部分。它本质就是一个普通函数名字以 use 开头内部可以调用其他 Hooks。它没有引入新的运行时概念只是把状态逻辑从组件里抽了出来。什么时候该抽我的标准很简单一组 state 和 effect 在逻辑上成块并且这块逻辑堆在组件里会让渲染代码变乱就抽。更可操作的信号是“两个组件都要用同一套逻辑”。比如多个页面都要读写 localStorage 形式的设置每次手写懒初始化 useEffect 持久化又容易漏那就应该抽成一个 useLocalStorageStatefunction useLocalStorageState(key, defaultValue) { const [state, setState] useState(() { const stored localStorage.getItem(key); return stored ! null ? JSON.parse(stored) : defaultValue; }); useEffect(() { localStorage.setItem(key, JSON.stringify(state)); }, [key, state]); return [state, setState]; }这个 hook 虽然只有十几行却把四个核心概念合在了一起useState 实现数据驱动useEffect 处理副作用返回数组完成状态向组件传递JSON.parse/JSON.stringify 则是隐式的状态派生。测试也方便因为它是普通函数的调用形态。另一个高频自定义 Hook 是防抖function useDebounce(value, delay 300) { const [debounced, setDebounced] useState(value); useEffect(() { const timer setTimeout(() setDebounced(value), delay); return () clearTimeout(timer); }, [value, delay]); return debounced; }注意这里的清理函数每一次 value 变化上一次的 timer 都会被清掉所以最终只有在停止变化 300ms 后debounced 值才会更新。这就是清理函数在日常业务里最常见的使用场景。自定义 Hook 还有一个容易踩的细节如果返回的是对象或函数最好用 useMemo/useCallback 固定引用否则调用方即使包了 React.memo也会因为拿到新引用而失效。换句话说你把状态管理逻辑收敛进 hook也要把引用稳定性的责任一起收敛进去。这个细节在我见过的问题里排得上前几很多人的 React.memo 完全不生效查到最后发现是自定义 Hook 每次返回新对象。至于和状态管理库的分工我的看法是很多项目的“全局状态”其实用 Context useReducer 自定义 Hook 就足够了。Redux、Zustand、Jotai 这类库的价值更多在于跨页面模块共享状态、复杂异步流程、调试工具和社区生态。如果只是“一个页面里多个组件共享表单状态”别急着引全局状态库。先写一个自定义 Hook通常你会发现逻辑已经很清晰了。7. 这些 Hooks 坑我都踩过依赖、闭包与重复渲染前六章讲的是原理和正向用法最后聊几个我在实际项目里踩过、也帮同事排查过的高频坑。它们几乎都能追溯到“渲染闭包”和“依赖语义”上。7.1 依赖数组缺项最常见的是 useEffect 里读取了某个 props但没放进依赖数组useEffect(() { fetchUser(user.id).then(setUser); }, []);第一次渲染 user.id 传入后请求没问题但切换用户时 effect 不会重新执行界面一直显示旧用户。这种 bug 隐蔽在于首次渲染大多是对的只有触发条件变化时才暴露。我的习惯是开 eslint-plugin-react-hooks 的 exhaustive-deps 规则并且不要轻易 ignore。如果依赖数组写全后 effect 变得过于频繁通常不是“依赖写多了”而是组件设计有问题——要么状态放的位置不对要么 effect 里该读的是更细粒度的值。7.2 setInterval 的闭包陷阱写倒计时常会这样const [count, setCount] useState(0); useEffect(() { const id setInterval(() setCount(count 1), 1000); return () clearInterval(id); }, []);结果永远停在 1。原因是 effect 闭包捕获了首次渲染的 count0之后每次 1 都是 01。修复方式就是函数式更新setCount(c c 1);函数式更新让 React 基于内部队列的最新值计算不再依赖闭包里的旧 count。如果 interval 里需要读取更复杂的状态可以用 useRef 保持一个最新值引用或者把状态逻辑迁到 useReducerdispatch 本身不依赖闭包状态。7.3 重复渲染的定位与修复我能想到的最常见性能问题是父组件持有大量 state其中一个 state 变化导致整棵子树重新渲染而大部分子组件根本不需要这个 state。快速定位用 React DevTools 的 Profiler 看火焰图轻量做法是在子组件函数体顶部 console.log(render)。修复手法通常有三个状态下放把只影响某个子组件的 state 放进那个子组件内部React.memo useCallback/useMemo 让 props 引用稳定用 children 隔离不变量。children 隔离是我很喜欢的一招父组件把“不随自身状态变化的 JSX”提前构造好作为 children 传给子组件子组件不会因为父组件重渲染而跟着重渲染。7.4 StrictMode 双执行并不是 bugReact 18 的 StrictMode 在开发环境下会刻意让渲染函数执行两次、effect setup/cleanup 也额外多跑一轮。很多人第一次看到 console.log 打印两遍第一反应是“代码写错了”。这是我见过最频繁的一次性惊吓。StrictMode 这么做是故意的目的是提前暴露“副作用不纯”的代码如果同一个 effect 被 setup 两次、cleanup 两次后还能保持一致状态说明它是干净的。对线上构建没有任何影响。所以遇到双调用先冷静检查 effect 有没有写清理函数而不是急着删 StrictMode。写到这里最后说一点个人的实际体会。我用了快四年 Hooks最深的感受是数据驱动、副作用、状态传递、状态派生这四个词不是四个孤立的 API 分类而是同一个问题的四个角度。真正需要管理的只有两样东西——哪些是必须存储的业务状态哪些是把状态带进现实世界时要做的事。遇到复杂需求我会先问自己三句话这个值真的需要 useState 存吗这个 effect 是不是每次渲染都要跑这个组件的数据是哪来的、要传给谁这三句话帮我拦下了不少改动希望你在自己的项目里也能少踩几个坑。