企业官网建设流程全解析

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来优化。

判断状态该放哪，我一般问三个问题：

1. 这个状态只被一个组件用吗？是的话就放在那个组件里。
2. 这个状态被多个组件用吗？是的话提升到共同父组件。
3. 这个状态需要跨层级传递吗？是的话考虑 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)，结果组件无限循环渲染，浏览器直接卡死。原因是每次渲染都会调用setState，setState又触发渲染，形成死循环。

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 会在合适的时机处理它。理解了这个区别，很多坑就不再是坑了。

如果你正在踩某个坑，或者刚踩完某个坑，欢迎对照上面的内容看看是不是同一类问题。如果上面没覆盖到，那说明我又可以更新这篇文章了。