JavaScript 闭包陷阱如何拖垮 React 渲染：从过期闭包到引用稳定的状态治理

引言

React 函数组件本质是一串「每次渲染都会重新执行」的函数，而 JavaScript 闭包会捕获它诞生那一刻的变量。这两个事实叠加，就催生了 React 开发里最顽固的一类 bug：过期闭包（Stale Closure）。组件里的回调拿到了旧 state、定时器读到旧 props、useCallback 返回的函数永远引用第一帧。本文不重复「闭包是什么」，只拆它如何污染状态读取，并给出可落地的收敛范式。

一、闭包捕获的是「那一刻的值」，不是「活变量」

JavaScript 的闭包捕获变量本身（而非值的快照），但函数组的每次渲染都会重新声明一套全新变量。上一帧的回调，引用的永远是上一帧的变量。

// 反例：定时器里的闭包永远看到 count = 0
function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      setCount(count + 1); // count 永远是首次渲染的 0
    }, 1000);
    return () => clearInterval(id);
  }, []); // 空依赖：effect 只跑一次，闭包永久锁定旧 count

  return <div>{count}</div>; // 界面永远是 1
}

useEffect 空依赖意味着它只执行一次，闭包捕获的 count 永远是初始值 0。setCount(count + 1) 每次都基于 0 算出 1，永远停在 1。

二、用函数式更新绕开「读旧值」

当更新依赖「前一个值」而非「当前渲染的值」时，把读取交给 setState 的函数式形式，闭包就不再需要捕获 count。

// 正例：函数式更新，闭包无需读取外部 count
function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      setCount((prev) => prev + 1); // 从「最新值」计算，不闭包旧值
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return <div>{count}</div>; // 每秒递增，正确
}

setCount((prev) => prev + 1) 把「读最新值」这件事交给了 React，闭包里不再有任何会过期的 count。这是处理「基于前值累加」场景的标准答案。

三、依赖数组是闭包的「保鲜清单」

闭包会过期，useCallback/useEffect 的依赖数组就是「告诉 React 何时重造这个闭包」的清单。漏掉依赖等于让闭包永久封存旧值。

// 反例：handleClick 引用了 role，但依赖数组漏了它
function UserPanel({ role }) {
  const handleClick = useCallback(() => {
    if (role === 'admin') { /* 管理员专属逻辑 */ }
  }, []); // 漏了 role：role 变化后，handleClick 仍引用旧 role

  return <Button onClick={handleClick} />;
}

role 变了，但 handleClick 因为依赖数组为空而从不重造，内部永远引用第一帧的 role。

// 正例：依赖数组完整列出闭包引用的所有变量
function UserPanel({ role }) {
  const handleClick = useCallback(() => {
    if (role === 'admin') { /* 管理员专属逻辑 */ }
  }, [role]); // role 变化时重建闭包

  return <Button onClick={handleClick} />;
}

依赖数组是「闭包保鲜清单」：凡是闭包体读到的、且可能变化的值，都必须列进去。react-hooks/exhaustive-deps 这条 lint 规则就是为自动发现这类遗漏而生。

四、useRef：给闭包一个「不过期的活值」

当某些值需要被闭包读取、但又不想它触发重渲染、也不想列进依赖时，useRef 提供了一条出路——它的 .current 是可变的活引用，闭包读到的是「当前值」而非「捕获值」。

// 反例：想在事件回调里读最新值，却陷入依赖地狱
function Chat({ onSend }) {
  const [draft, setDraft] = useState('');

  // 每次 draft 变化都要重建 handleSend，否则回调里是旧 draft
  const handleSend = useCallback(() => {
    onSend(draft);
  }, [draft, onSend]);

  return <Input value={draft} onChange={(e) => setDraft(e.target.value)} />;
}

每敲一个字，draft 变一次，handleSend 重建一次，引用稳定性被彻底破坏。

// 正例：用 ref 持有最新 draft，回调保持稳定引用
function Chat({ onSend }) {
  const [draft, setDraft] = useState('');
  const draftRef = useRef(draft);
  draftRef.current = draft; // 每次渲染同步最新值

  const handleSend = useCallback(() => {
    onSend(draftRef.current); // 总是读到最新 draft，且引用稳定
  }, [onSend]);

  return <Input value={draft} onChange={(e) => setDraft(e.target.value)} />;
}

draftRef.current = draft 在渲染期同步，handleSend 依赖只有 onSend，引用稳定，且读到的永远是当前 draft。useRef 是「给闭包一个活门」，而非重造闭包本身。

五、过期闭包的完整治理清单

把上面的手段归位，形成一张可对照的决策表：

// 正例：四类场景一句话对应
// 1. 基于前值累加        -> setState(prev => ...)
// 2. 读 props/state 做副作用 -> 列全依赖数组，交给 exhaustive-deps
// 3. 需要稳定引用但读最新值 -> useRef 同步 + useCallback([稳定依赖])
// 4. 订阅式读取            -> useEffect 内注册监听，清理函数里解绑

// 反模式速查
//   空依赖数组 + 读 state：闭包锁定首帧值
//   依赖数组漏变量：闭包过期，且 lint 报 warning 却被忽略
//   每次渲染都内联箭头：引用永远不稳定，拖垮 memo 子组件

其中最关键的一条：别把 useCallback/useMemo 当成「性能优化开关」，当成「引用身份管理」。它的价值在于让引用稳定，阻止下游 memo 组件无谓重渲染，而不是省下几次函数创建。

结语

React 里的闭包问题，本质是「函数组件的每次渲染都重造变量」撞上了「闭包捕获诞生时的变量」这条 JS 铁律。治理它没有捷径，只有三条清晰的路径：需要累加就用函数式更新、需要保鲜就列全依赖、需要稳定引用就上 useRef。当你不再把「依赖数组」和「闭包」当成两个孤立概念，而是看成「闭包的生命周期由依赖数组决定」这一件事时，过期闭包就从玄学变成了可预测、可静态检查的工程问题。