1. 从一次线上白屏说起useState 的异步陷阱那天晚上十一点测试同学在群里甩了一张截图页面白得像一张A4纸控制台里一行红字格外刺眼Cannot read properties of undefined (reading length)。我盯着代码看了半天逻辑上完全说得通——点击按钮setList更新列表然后立刻读取list.length做后续判断。可偏偏就是这里出了问题。后来我才反应过来useState的更新是异步的setList之后的那行代码读到的还是旧值。这个坑我踩过不止一次而且每次踩的时候都觉得这次肯定没问题结果每次都被现实教育。useState看起来是 React 里最简单的 Hook没有之一但恰恰因为它太简单很多人包括曾经的我会下意识地把它当成普通变量来用忽略了它背后那套状态更新机制。这篇文章不打算复述官方文档而是想把我这些年在实际项目里踩过的useState坑一个个拆开讲清楚每个坑背后的原理、为什么容易踩、怎么排查、怎么修以及怎么在团队里避免重复踩。如果你正在用 React 做项目不管是刚入门还是已经写了几年只要还在用函数组件useState就绕不开。下面这些内容有些是新手必踩的有些是写了很久之后才突然意识到的我会尽量用当时怎么想的、实际发生了什么、后来怎么改的这种顺序来讲方便你对照自己的代码。2. 闭包陷阱为什么我的定时器永远读到旧状态2.1 一个倒计时组件的诡异行为先看一段代码这是我早期写的一个倒计时组件简化后大概长这样function Countdown() { const [count, setCount] useState(10); useEffect(() { const timer setInterval(() { setCount(count - 1); }, 1000); return () clearInterval(timer); }, []); return div{count}/div; }当时我的预期是每秒减一从10减到0。实际跑起来数字从10跳到9然后就卡在9不动了。我一开始以为是setInterval没生效加了console.log才发现回调确实每秒都在执行但count始终是10所以每次setCount(10 - 1)都是设成9。问题出在闭包上。useEffect的依赖数组是空的意味着这个 effect 只在挂载时执行一次它捕获的是第一次渲染时的count也就是10。之后不管count怎么变这个闭包里的count永远是10。这就是所谓的闭包陷阱或者叫陈旧闭包stale closure。2.2 两种修法以及它们各自的代价最直接的修法是改用函数式更新setCount(prev prev - 1);这样就不依赖闭包里的count了React 会把最新的状态传进prev。这是官方推荐的做法也是我后来最常用的方式。另一种修法是把count加进依赖数组useEffect(() { const timer setInterval(() { setCount(count - 1); }, 1000); return () clearInterval(timer); }, [count]);但这样写有个副作用每次count变化effect 都会重新执行定时器被清掉又重新创建。对于倒计时来说这会导致计时不准因为每次重建定时器都会重置间隔。所以依赖数组不是随便加的加之前要想清楚这个 effect 到底依赖什么、重建的代价是什么。提示判断该用函数式更新还是加依赖一个简单的标准是——如果你在回调里只需要基于前一个状态计算新状态优先用函数式更新如果回调里还需要用到其他外部变量那就要认真考虑依赖数组了。2.3 闭包陷阱的通用识别方法闭包陷阱不只出现在定时器里任何在某个回调或异步操作里读取状态的场景都可能中招。比如setTimeout里读取状态事件监听器里读取状态Promise 的then里读取状态订阅回调里读取状态识别方法很简单问自己一句这个回调执行的时候它捕获的是哪一次渲染的状态如果答案是不确定或者第一次渲染的那基本就是闭包陷阱。我现在的习惯是只要在 effect 或回调里用到状态先想一下要不要用函数式更新或者要不要把状态放进依赖数组。3. 批量更新与渲染次数setState 之后到底发生了什么3.1 连续调用三次 setCount为什么只渲染一次有一次我在做一个计数器需要在一次点击里加3我写了三行setCount(count 1); setCount(count 1); setCount(count 1);结果只加了1。我当时以为是 React 出了 bug后来才明白这是 React 的批量更新机制。在 React 18 之前只有 React 事件处理函数里的更新会被批量处理React 18 之后所有更新默认都会批量处理包括setTimeout、Promise 里的更新。批量更新的逻辑是React 会把同一个事件循环里的多次setState收集起来等事件处理结束后统一计算新状态然后只触发一次渲染。所以上面三行代码里count都是同一个旧值三次setCount(count 1)等价于把count设成count 1最终只加1。正确的写法还是函数式更新setCount(prev prev 1); setCount(prev prev 1); setCount(prev prev 1);这样每次prev都是上一次更新后的值最终加3。3.2 批量更新带来的状态不同步错觉批量更新还有一个容易让人困惑的地方你在setState之后立刻读取状态读到的还是旧值。比如setCount(count 1); console.log(count); // 还是旧值这不是 bug而是因为状态更新是异步的setCount只是安排了一次更新真正的更新要等到当前执行栈清空之后。如果你确实需要在状态更新后做点什么应该用useEffect监听状态变化而不是在setState后面直接写代码。我见过有同学为了拿到最新状态在setState后面加setTimeout这其实是一种 hack虽然有时候能work但不可靠而且会让代码逻辑变得难以理解。正确的做法是接受状态更新是异步的这个事实用 effect 来处理副作用。3.3 什么时候需要关心渲染次数大部分情况下React 的批量更新和渲染优化已经做得足够好你不需要手动干预。但有两种场景需要留意第一种是状态更新非常频繁的场景比如拖拽、滚动、输入框实时搜索。如果每次更新都触发渲染而且渲染成本很高就可能卡顿。这时候可以考虑用useMemo、useCallback减少不必要的计算或者用防抖、节流控制更新频率。第二种是多个状态需要同步更新的场景。比如一个表单有name和age两个状态提交时需要同时读取它们。如果分开更新可能会出现name 更新了但 age 还没更新的中间状态。这时候可以考虑用useReducer把多个状态合并成一个或者用useRef保存一份最新值。4. 初始值的惰性求值别让 useState 每次都做无用功4.1 一个昂贵的初始值计算假设你要初始化一个状态初始值需要经过复杂计算const [data, setData] useState(expensiveCalculation());这段代码的问题在于expensiveCalculation()每次渲染都会执行一次即使它的结果只用于第一次渲染。因为useState的参数是在调用时求值的React 并不知道这个值只在初始化时用。正确的写法是传一个函数const [data, setData] useState(() expensiveCalculation());这样expensiveCalculation只会在组件首次挂载时执行一次。这个细节在官方文档里有写但很容易被忽略因为大部分时候初始值计算都很便宜感觉不到差异。只有当初始值涉及大量计算、读取本地存储、解析复杂数据时这个差异才会显现出来。4.2 惰性初始化的适用场景我总结了几种适合用惰性初始化的场景初始值需要从localStorage或sessionStorage读取并解析初始值需要对大数组或对象做过滤、排序、映射初始值需要根据 props 做复杂计算初始值需要调用某个可能耗时的工具函数反过来如果初始值就是一个简单的字面量比如useState(0)、useState()、useState([])那就没必要包一层函数反而增加阅读负担。注意useState([])和useState(() [])在行为上有一点细微差别。前者每次渲染都会创建一个新数组后者只在初始化时创建。如果这个数组作为依赖传给子组件或 effect前者可能导致不必要的重渲染或 effect 重执行。所以对于对象和数组类型的初始值用惰性初始化是个好习惯。4.3 惰性初始化与函数式更新的区别这两个概念容易混淆我一开始也搞混过。简单说惰性初始化useState(() initialValue)解决的是初始值计算太贵的问题函数式更新setState(prev newValue)解决的是更新时依赖旧状态的问题两者都用函数但用途完全不同。一个用在useState的参数里一个用在setState的参数里。记住这个区别就不会用错了。5. 状态提升与组件拆分什么时候该把状态放哪里5.1 状态放错位置导致的重复渲染我曾经做过一个搜索框组件输入框和结果列表放在同一个组件里状态也放在这个组件里。每次输入整个组件重新渲染结果列表也跟着重新渲染即使列表数据没变。后来我把输入框和结果列表拆成两个组件输入状态放在父组件结果列表用React.memo包裹问题就解决了。这个经历让我意识到useState放的位置直接影响渲染范围。状态放在哪个组件哪个组件及其子组件就会在状态变化时重新渲染。所以一个原则是状态尽量放在离使用它的组件最近的地方避免放在顶层导致大范围重渲染。5.2 状态提升的时机但有时候状态又需要提升。比如两个兄弟组件需要共享同一个状态那就得把状态提升到它们的共同父组件。这时候父组件会重新渲染两个子组件也会重新渲染。如果子组件渲染成本高可以用React.memo配合useCallback来优化。判断状态该放哪我一般问三个问题这个状态只被一个组件用吗是的话就放在那个组件里。这个状态被多个组件用吗是的话提升到共同父组件。这个状态需要跨层级传递吗是的话考虑 Context 或状态管理库。5.3 一个常见的反模式把所有状态都放在顶层我见过一些项目所有状态都放在最顶层的 App 组件里然后一层层往下传。这种写法在小型项目里还能忍一旦组件层级深了props 传递会变得非常痛苦而且任何状态变化都会导致整个应用重新渲染。更好的做法是按功能模块拆分状态每个模块有自己的状态管理。React 本身提供了 Context 来做跨层级共享对于更复杂的场景可以用专门的状态管理方案。但不管用什么方案核心原则是一样的状态应该放在它被需要的地方而不是为了方便就全部堆在顶层。6. 那些年我踩过的其他 useState 坑6.1 直接修改状态对象或数组这是新手最容易犯的错误之一const [list, setList] useState([1, 2, 3]); list.push(4); setList(list);这样写React 会认为状态没变因为list的引用还是同一个。正确的做法是创建一个新数组setList([...list, 4]);对象也一样不能直接改属性要用展开运算符或Object.assign创建新对象。这个坑的根源在于 React 用Object.is来比较新旧状态引用不变就认为没变。6.2 在渲染中调用 setState有一次我不小心在组件函数体里直接写了setCount(count 1)结果组件无限循环渲染浏览器直接卡死。原因是每次渲染都会调用setStatesetState又触发渲染形成死循环。setState只能在事件处理函数、effect、回调里调用不能在渲染过程中调用。如果确实需要根据 props 或状态派生新状态应该用useMemo或者在 effect 里处理。6.3 状态更新后立即读取的误区前面提过setState之后立即读取状态拿到的是旧值。但还有一种情况更隐蔽在useEffect里读取状态但依赖数组没写对导致 effect 执行时读到的是旧状态。这种问题往往表现为有时候对有时候不对排查起来很头疼。我的经验是只要在 effect 里用到状态就把状态写进依赖数组除非你明确知道不需要。如果加了依赖导致 effect 频繁执行那说明你的 effect 设计可能有问题应该考虑拆分或改用其他方式。6.4 多个状态更新的顺序问题当多个状态需要一起更新时分开写setState可能会导致中间状态不一致。比如setLoading(true); setData(newData); setLoading(false);如果这三行在同一个事件处理函数里React 会批量处理最终loading是false看起来没问题。但如果中间有异步操作或者在其他场景下就可能出现loading为true但data还没更新的中间状态。对于这种关联状态用useReducer或者合并成一个对象状态会更安全。7. 排查 useState 问题的实用套路7.1 先确认是不是闭包问题遇到状态不更新或读到旧值的问题我第一步就是检查闭包。具体做法是找到读取状态的那行代码看它所在的函数是在哪次渲染时创建的。如果是 effect、定时器、事件监听器里的回调而且依赖数组是空的或者没包含这个状态那基本就是闭包问题。确认之后改法有两种用函数式更新或者把状态加进依赖数组。选哪种取决于具体场景前面已经讲过判断标准。7.2 用 console.log 定位渲染次数如果怀疑组件渲染次数异常可以在组件函数体里加console.log(render)观察输出频率。如果每次操作都打印很多次说明有不必要的重渲染。这时候可以检查状态是不是放在太顶层了有没有在渲染中创建新对象或新函数传给子组件子组件有没有用React.memo包裹7.3 用 React DevTools 观察状态变化React DevTools 的 Components 面板可以实时查看每个组件的状态和 props还能看到组件为什么重新渲染。我排查复杂问题时经常用它比加console.log高效得多。特别是为什么这个组件渲染了这个功能能直接告诉你是因为 props 变了、状态变了还是父组件渲染了。7.4 写一个最小复现如果问题很诡异怎么都找不到原因我会新建一个文件把相关代码精简到最少只保留能复现问题的部分。这个过程本身往往就能发现问题因为精简的过程中你会被迫想清楚每个状态的作用和依赖关系。很多次我都是在写最小复现的时候突然意识到哦原来是这里。8. 团队协作中如何避免重复踩坑8.1 把常见坑写进代码规范我们团队后来整理了一份 React 编码规范其中关于useState的部分包括更新状态时优先使用函数式更新对象和数组状态必须创建新引用effect 里用到的状态必须写进依赖数组初始值计算复杂时使用惰性初始化禁止在渲染过程中调用setState这些规范不是凭空写的每一条背后都有对应的线上问题或 code review 争论。写进规范之后新同学上手时至少知道有哪些坑不用每个人都踩一遍。8.2 code review 时重点关注状态逻辑在 code review 时我会特别关注状态相关的代码。比如看到setState后面直接跟读取状态的代码就会问一句这里拿到的是最新值吗看到 effect 依赖数组为空但里面用了状态就会提醒可能有闭包问题。这种 review 不仅能发现问题还能帮助团队成员建立对状态更新的敏感度。8.3 用 ESLint 插件自动检查eslint-plugin-react-hooks可以自动检查 Hook 的使用规范包括依赖数组是否完整、是否在条件语句里调用 Hook 等。虽然它不能覆盖所有坑但能拦住大部分低级错误。我们团队的项目都配了这个插件配合 CI 检查能在提交前就发现很多问题。9. 写在最后useState 的简单与不简单useState的 API 确实简单一个值、一个设置函数仅此而已。但简单不等于容易它背后的异步更新、闭包、批量处理、引用比较这些机制每一个都可能成为坑。我写这篇文章不是想吓唬谁而是想说这些坑我都踩过而且踩的时候都觉得自己不会踩。现在回头看大部分坑的根源其实是一个思维方式的转变——从命令式思维转向声明式思维。在命令式编程里你改变一个变量它立刻就变了在 React 里你请求一次状态更新React 会在合适的时机处理它。理解了这个区别很多坑就不再是坑了。如果你正在踩某个坑或者刚踩完某个坑欢迎对照上面的内容看看是不是同一类问题。如果上面没覆盖到那说明我又可以更新这篇文章了。