引言
“我明明点了十次按钮，为什么控制台还在说 count 是 0？”
—— 每一个刚接触 React Hooks 的开发者，几乎都曾被这个问题狠狠“教育”过。
今天，我们就来彻底揭开 React 中的“闭包陷阱” （Closure Trap）这一经典问题的神秘面纱。我们将通过一段真实代码、深入原理剖析、对比错误与正确写法，并解释 为什么依赖项如此重要。无论你是初学者还是有经验的开发者，这篇文章都会让你对 React 的执行机制和闭包行为有更清晰的认识。
问题复现：一段看似无害的代码
先来看这段你可能写过无数次的代码：
import {
useState,
useEffect
} from 'react'
export default function App() {
const [count, setCount] = useState(0)
console.log('----------')
useEffect(() => {
const timer = setInterval(() => {
console.log('Current count:', count)
}, 1000)
// return的clearInterval函数不只是组件卸载时调用
// 每次useEffect重新执行之前，都会执行上一次的clearInterval函数
return () => { clearInterval(timer) }
// }, []) // 此处没有依赖项 count，会导致闭包陷阱 ，运行时会出现访问到旧值的情况 一直显示'Current count: 0'
}, [count]) // 此处一定要加依赖项 count，否则会导致闭包陷阱
return (
<>
<p>count: {count}</p>
<button onClick={() => setCount(count + 1)}>count + 1</button>
</>
)
}
乍一看，这段代码逻辑清晰：
- 点击按钮，
count加 1； - 每隔 1 秒，打印当前
count值。
但如果你把 useEffect 的依赖项写成空数组 []（即注释掉 [count] 的那一行），神奇的事情发生了：
控制台永远输出：
Current count: 0，哪怕你点击了 100 次！
这，就是 React 闭包陷阱 的典型表现。
什么是闭包陷阱？
闭包本身不是问题
首先澄清一点：闭包是 JavaScript 的正常特性，不是 bug。它允许内部函数“记住”并访问其创建时所在作用域中的变量。
但在 React 函数组件中，每一次渲染都会生成全新的函数作用域。这意味着每次 App() 被调用（即每次 state 变化触发重新渲染），都会创建一组全新的变量（如 count）和函数（如 setCount、useEffect 回调等）。
陷阱在哪里？
当我们在 useEffect 中使用了某个状态变量（比如 count），却没有把它加入依赖数组时，就会导致：
useEffect 的回调函数“捕获”了第一次渲染时的
count值（即 0），并在后续所有执行中始终使用这个“快照” 。
这就是所谓的 “闭包陷阱” —— 并非闭包错了，而是我们错误地让闭包“锁住”了一个过期的状态。
深入原理：React 渲染、Effect 与闭包的关系
让我们一步步拆解整个过程。
第一次渲染（count = 0）
-
App()执行。 -
useState(0)返回count = 0。 -
useEffect被调用（因为依赖项是[]，只在首次挂载时运行）。 -
在
useEffect内部：- 创建
setInterval，其回调函数引用了当前作用域的count（值为 0）。 - 这个回调函数形成了一个闭包，牢牢“记住”了
count = 0。
- 创建
-
组件挂载完成。
此时，定时器开始每秒打印 'Current count: 0'。
用户点击按钮（count 变为 1）
-
setCount(1)被调用。 -
React 触发第二次渲染。
-
App()再次执行：useState返回count = 1。- 但由于
useEffect的依赖是[]，它不会重新执行！ - 所以之前的
setInterval依然在运行，且它的闭包中count仍然是 0。
-
页面显示
count: 1，但控制台仍打印0。
后续点击（count = 2, 3, 4...）
同理：useEffect 不会重新运行，定时器回调始终使用第一次渲染时捕获的 count = 0。
💡 关键点：定时器回调函数是在第一次渲染的作用域中定义的，它只能看到那个时刻的变量值。
正确做法：把依赖项加上！
现在，我们把依赖项改为 [count]：
}, [count]) // 此处一定要加依赖项 count，否则会导致闭包陷阱
会发生什么变化？
每次 count 改变，useEffect 都会重新执行！
-
第一次渲染：
count = 0→ 启动定时器 A（打印 0）。 -
点击按钮 →
count = 1→ 第二次渲染：- React 先调用上一次
useEffect返回的清理函数：clearInterval(timerA)。 - 然后执行新的
useEffect：启动定时器 B（打印 1）。
- React 先调用上一次
-
再次点击 →
count = 2→ 第三次渲染：- 清理定时器 B。
- 启动定时器 C（打印 2）。
这样，每个定时器都“绑定”到它创建时的最新 count 值，控制台就能正确输出当前值。
✅ 这正是 React 官方推荐的模式：Effect 应该明确声明它所依赖的所有响应式值。
为什么很多人一开始会写 []？
常见误区包括：
- 误以为
useEffect类似于 class 组件的componentDidMount，只想在“挂载时”运行一次。 - 担心频繁创建/销毁定时器会影响性能。
- 不了解闭包在 React 渲染循环中的行为。
但 React 的哲学是：不要对抗重渲染，而是拥抱它。正确的依赖管理比“避免重运行”更重要。
补充说明：清理函数的调用时机
注意代码中的注释：
// return的clearInterval函数不只是组件卸载时调用
// 每次useEffect重新执行之前，都会执行上一次的clearInterval函数
这是 React 的一个重要机制：
每当依赖项变化导致
useEffect重新运行时，React 会先调用上一次返回的清理函数，再执行新的 Effect。
这确保了资源（如定时器、订阅、WebSocket 连接等）不会泄漏，也避免多个定时器同时运行。
其他避免闭包陷阱的方法（进阶）
虽然添加依赖项是最直接的方式，但在某些场景下（比如高性能动画或复杂逻辑），频繁重建定时器可能不理想。这时可以考虑：
方法 1：使用 useRef 保存最新值
const countRef = useRef(count);
useEffect(() => {
countRef.current = count;
}, [count]);
useEffect(() => {
const timer = setInterval(() => {
console.log('Current count:', countRef.current); // 总是最新值
}, 1000);
return () => clearInterval(timer);
}, []); // 依赖为空，但通过 ref 获取最新值
注意：这种方式绕过了 React 的响应式模型，应谨慎使用。
方法 2：使用函数式更新（适用于 setState）
如果只是想在定时器中更新状态，可以用：
setInterval(() => {
setCount(c => c + 1); // 基于最新状态计算
}, 1000);
但这不适用于“读取”状态（如日志打印）。
总结：如何避免闭包陷阱？
| 场景 | 错误做法 | 正确做法 |
|---|---|---|
在 useEffect 中使用状态变量 | 依赖项为空 [] | 将变量加入依赖数组 [count] |
| 需要长期运行的副作用（如 WebSocket） | 忽略依赖 | 使用 useRef 或合理设计依赖 |
| 不确定依赖项 | 随意省略 | 使用 ESLint 插件 eslint-plugin-react-hooks 自动检测 |
📌 黄金法则：只要你在 Effect、Callback 或其他闭包中用了某个响应式值（state、props、由它们派生的值），就必须把它加入依赖数组！
结语
React 的闭包陷阱，本质上不是 React 的缺陷，而是 函数式编程 + 响应式更新 模型带来的自然结果。理解它，不仅能写出更健壮的代码，还能真正掌握 React 的心智模型。
下次当你看到控制台打印出“过期”的状态时，别慌——
检查你的依赖项，闭包陷阱就无处遁形！
📚 延伸阅读：
希望这篇文章帮你彻底搞懂闭包陷阱！如果你觉得有用，欢迎分享给正在“被 0 困扰”的朋友 😄
