2.13 闭包陷阱与 stale closure

一句话：闭包陷阱（stale closure）指「函数捕获了某次渲染的变量快照，之后读到的永远是那个旧值」——它是 React 里最隐蔽也最常见的一类 bug，根因是「每次渲染都是一次新的函数调用」。

一、什么是闭包陷阱

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      console.log(count);        // ⚠️ 永远打印 0
    }, 1000);
    return () => clearInterval(id);
  }, []);                        // ⚠️ 依赖是空的

  return (
    <>
      {count}
       setCount((c) => c + 1)}>+1
    
  );
}
// 现象：点按钮，界面上的数字在变，但控制台一直打印 0

为什么会这样？

① 每次组件渲染，都会【重新执行一次组件函数】→ 产生一个新的作用域
   · 第 1 次渲染：count = 0，创建了 setInterval 的回调 A（捕获了 count = 0）
   · 第 2 次渲染：count = 1，创建了新的回调 B（捕获了 count = 1）
② 但 useEffect 的依赖是 [] → 只在挂载时执行一次
   → 只注册了回调 A，之后再也不重新注册
③ 于是定时器里永远执行「第 1 次渲染的那个闭包」→ 读到的永远是 0

这就叫 stale closure（陈旧闭包）：
  闭包捕获的是【某一次渲染】的变量，而不是「实时的变量」。

二、四个典型场景

// ① 定时器里读 state
useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1);        // ⚠️ 每次都设为「初始值 + 1」
  }, 1000);
  return () => clearInterval(id);
}, []);

// ② 事件监听里读 state
useEffect(() => {
  const onKeyDown = (e: KeyboardEvent) => {
    if (e.key === 'Enter') submit(formData);   // ⚠️ formData 是旧的
  };
  window.addEventListener('keydown', onKeyDown);
  return () => window.removeEventListener('keydown', onKeyDown);
}, []);

// ③ 异步回调里读 state / props
async function handleClick() {
  await delay(1000);
  console.log(count);           // ⚠️ 1 秒前的 count（如果期间变了）
  setCount(count + 1);          // ⚠️ 基于旧值计算
}

// ④ 防抖/节流回调里读 state
const debouncedSearch = useMemo(
  () => debounce(() => {
    search(filter);             // ⚠️ 首次渲染时的 filter
  }, 300),
  []                            // ⚠️ 依赖空 → 永远只用第一次的闭包
);

三、解法一：补齐依赖（首选）

// ✅ 把用到的值写进依赖数组
useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1);        // 现在 count 是最新的
  }, 1000);
  return () => clearInterval(id);
}, [count]);                     // ⭐ 每次 count 变化都重建定时器

✅ 优点：语义正确、最符合 React 的模型
⚠️ 缺点：会「重建」副作用（定时器被清掉重开、监听被解绑重绑）

什么时候「重建」是可接受的？
  · 大多数场景可以接受（重建成本低）
  · 但「定时器」重置会导致计时不准（每次 count 变化都重新计时）

如果需要「不重建但读最新值」→ 用解法二。

四、解法二：用 useRef 保存最新值（推荐用于定时器/订阅）

// ✅ 模式：用 ref 保存最新值，副作用只建立一次
function Counter() {
  const [count, setCount] = useState(0);

  const countRef = useRef(count);
  useEffect(() => {
    countRef.current = count;    // 每次渲染都把最新值写进 ref（不触发渲染）
  });

  useEffect(() => {
    const id = setInterval(() => {
      console.log(countRef.current);   // ⭐ 读到最新值，且定时器不会重建
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return 
{count}
;
}

// 更通用的封装：useInterval（社区常见写法）
function useInterval(callback: () => void, delay: number | null) {
  const savedCallback = useRef(callback);

  // 每次渲染同步最新回调（依赖变化时不重建定时器）
  useEffect(() => {
    savedCallback.current = callback;
  }, [callback]);

  useEffect(() => {
    if (delay === null) return;
    const id = setInterval(() => savedCallback.current(), delay);
    return () => clearInterval(id);
  }, [delay]);                     // ⭐ 只有 delay 变化才重建
}

// 使用：callback 里可以安全地读最新的 state / props
function Timer() {
  const [count, setCount] = useState(0);

  useInterval(() => {
    setCount(count + 1);           // ✅ 读的是最新 count
  }, 1000);

  return 
{count}
;
}

// 同样的模式用于事件监听
function useEventListener(
  type: K,
  handler: (e: WindowEventMap[K]) => void
) {
  const handlerRef = useRef(handler);
  useEffect(() => { handlerRef.current = handler; });

  useEffect(() => {
    const listener = (e: WindowEventMap[K]) => handlerRef.current(e);
    window.addEventListener(type, listener);
    return () => window.removeEventListener(type, listener);
  }, [type]);                      // ⭐ 只依赖 type
}

五、解法三：函数式更新（针对 setState）

// ❌ 基于「闭包里的旧值」计算
useEffect(() => {
  const id = setInterval(() => setCount(count + 1), 1000);   // count 永远是 0
  return () => clearInterval(id);
}, []);

// ✅ 用函数式更新：不读闭包里的 count，让 React 用最新值去算
useEffect(() => {
  const id = setInterval(() => setCount((c) => c + 1), 1000);   // 正确累加
  return () => clearInterval(id);
}, []);

适用范围：
✅ setCount((c) => c + 1)          —— 新值只依赖旧值
❌ setItems([...items, newItem])   —— 除了旧值还需要 items 的内容（其实也可以写
                                     setItems((prev) => [...prev, newItem]) ✅）

换句话说：只要「计算新值的逻辑能只依赖旧值」，就能用函数式更新绕开闭包陷阱。
如果需要「读其它的 state / props」，就得用解法一或二。

六、解法四：三种解法的选择

// 「事件处理里不需要处理」的解释
function Comp() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    console.log(count);          // ✅ 这就是「点击那一刻」的值
    // 原因：handleClick 是「本次渲染」创建的，所以它捕获的是本次渲染的 count
    // 用户在界面上看到的就是本次渲染的 count —— 两者一致，符合直觉
  };

  return {count};
}

理解这一点的关键：闭包陷阱只在「回调的生命周期长于一次渲染」时出现（定时器、订阅、异步任务、缓存起来的函数）。事件处理函数的生命周期就是「本次渲染」，所以不构成陷阱。

七、关于 useEvent / useEffectEvent

社区长期存在一个提案：useEvent（后改名 useEffectEvent）

它的语义是：
  「一个永远能读到最新 props/state、但【引用永远稳定】的函数」

  const onVisit = useEffectEvent((url) => {
    logVisit(url, numberOfItems);   // 永远读到最新值，且不成为依赖
  });

  useEffect(() => {
    onVisit(url);
  }, [url]);                        // 依赖里【不需要】写 numberOfItems

这正好解决了本节的痛点：既想读最新值，又不想把它写进依赖。

现状（截至 React 19）：
  · useEffectEvent 在 React 19 中仍处于【实验阶段】（从 experimental 通道提供）
  · 目前生产环境仍应使用「useRef 保存最新值」的模式
  · 可以自己封装一个简易的 useEvent：
    function useEvent any>(fn: T): T {
      const ref = useRef(fn);
      useEffect(() => { ref.current = fn; });
      return useCallback((...args) => ref.current(...args), []) as T;
    }

// 自己封装 useEvent（在 useEffectEvent 稳定前可用的替代）
function useEvent any>(handler: T): T {
  const ref = useRef(handler);
  useEffect(() => { ref.current = handler; });

  return useCallback((...args: Parameters) => ref.current(...args), []) as T;
}

// 使用：引用稳定 + 读最新值
function Comp({ url }: { url: string }) {
  const [items, setItems] = useState([]);

  const onVisit = useEvent(() => {
    // 引用稳定（可以安全地放进依赖），且能读到最新的 items
    logVisit(url, items.length);
  });

  useEffect(() => {
    onVisit();
  }, [onVisit]);            // ✅ onVisit 引用稳定 → Effect 只在挂载时执行一次

  return null;
}

八、常见坑

// ① 用「删除依赖」来消除 eslint 警告 → 制造闭包陷阱
useEffect(() => {
  setCount(count + 1);
}, []);                     // ❌ 警告被消除了，但逻辑错了

// ② 在 useMemo/useCallback 里用「未声明的依赖」
const fn = useCallback(() => doSomething(user), []);   // ❌ user 是旧值

// ③ 把「需要最新值的回调」直接传给第三方库（会被缓存）
useEffect(() => {
  const chart = new Chart(el, { onRender: () => setData(count) });  // ❌
}, []);

// ④ 在防抖/节流里读 state（且依赖为空）
const debounced = useMemo(() => debounce(() => search(filter), 300), []);   // ❌

// ⑤ 在 setTimeout 里读 state
setTimeout(() => setCount(count + 1), 1000);           // ❌ 用函数式更新

// ⑥ 认为「用 useRef 保存最新值」是 hack
// → 这是 React 官方推荐的处理方式之一（React 文档里有明确示例）

// ⑦ 用 ref 保存最新值但忘了「每次渲染都更新」
const countRef = useRef(count);
// ❌ 没有 useEffect(() => { countRef.current = count; })
// → ref 里永远是初始值

// ⑧ 在类组件里没有这个问题，误以为函数组件也一样
// → 类组件的 this.props / this.state 是【实时读取】的，不会有这个陷阱

// ⑨ 用「函数式更新」但逻辑不满足「只依赖旧值」
setItems((prev) => {
  return [...prev, ...fetchFromOtherSource()];        // ⚠️ 依赖了外部数据（可能过期）
});

// ⑩ 给第三方库传回调时忘记用 useEvent/ref 模式
// → 库缓存了回调，之后一直用旧闭包

九、一个完整的对比示例

// 需求：一个「自动保存草稿」的组件（每 3 秒保存一次最新的输入）

// ❌ 错误实现：闭包陷阱
function useAutoSaveBad(content: string) {
  useEffect(() => {
    const id = setInterval(() => {
      saveDraft(content);              // ⚠️ 永远是首次渲染时的 content
    }, 3000);
    return () => clearInterval(id);
  }, []);
}

// ✅ 解法一：补齐依赖（每次输入都重建定时器）
function useAutoSaveGood1(content: string) {
  useEffect(() => {
    const id = setInterval(() => {
      saveDraft(content);
    }, 3000);
    return () => clearInterval(id);
  }, [content]);                       // ⭐ 每次 content 变化都重建
  // ⚠️ 副作用：定时器会不断重置 → 如果用户一直在输入，可能永远不保存
  //    需要「固定间隔保存」的场景不适合这种解法
}

// ✅ 解法二：ref 保存最新值（定时器不重建）—— 推荐
function useAutoSave(content: string) {
  const contentRef = useRef(content);
  useEffect(() => { contentRef.current = content; });

  useEffect(() => {
    const id = setInterval(() => {
      saveDraft(contentRef.current);   // ⭐ 读到最新内容，定时器不重置
    }, 3000);
    return () => clearInterval(id);
  }, []);
}

面试延伸

1. 「什么是闭包陷阱（stale closure）？」
   指「函数捕获了某次渲染的变量快照，之后读到的永远是那个旧值」。成因是「每次渲染都会重新执行组件函数、产生新的作用域」——如果某个回调被「长期持有」（如 setInterval、事件订阅、缓存的防抖函数），它就会一直引用创建它那次渲染的变量，看不到后续的变化。典型现象是「界面上的数字在变，但定时器里打印的永远是初始值」。

2. 「为什么会有闭包陷阱？」
   因为 React 的渲染模型是「每次渲染 = 一次函数调用 = 一套新的变量」。组件函数里声明的 count 是那次渲染的常量，而 setInterval 的回调捕获的是创建它时那个作用域。当副作用只建立一次（依赖写 []）而变量会变化时，回调与变量就「脱节」了——这就是陈旧的由来。根本原因在于 JS 的闭包语义与 React 的「重复调用渲染函数」模型叠加。

3. 「怎么解决闭包陷阱？」
   四种方式：① 补齐依赖（最简单、语义最正确，代价是副作用会重建）；② 用 useRef 保存最新值（ref.current 每次渲染更新，副作用只建立一次也能读最新值——适合定时器/订阅）；③ 函数式更新（setCount(c => c + 1)，把「计算」交给 React，不读闭包里的值）；④ useEvent 模式（自己封装「引用稳定 + 读最新值」的函数）。首选是补齐依赖，需要「不重建副作用」时用 useRef。

4. 「事件处理函数里会有闭包陷阱吗？」
   不会。因为事件处理函数的生命周期恰好是「本次渲染」——它在本次渲染中创建、在本次渲染的界面上被触发，所以它捕获的值与「用户看到的界面」是一致的，符合直觉。闭包陷阱只在「回调的生命周期长于一次渲染」时出现：定时器、事件订阅、异步任务、被缓存起来的函数（防抖/节流）、传给第三方库的回调。

5. 「为什么类组件没有这个问题？」
   因为类组件里读的是 this.props / this.state——this 是同一个实例对象，它的属性是实时读取的（每次访问都取当前值）。而函数组件每次渲染都会创建新的闭包变量，回调捕获的是其中某一份。这是「函数组件的心智模型」与「类组件的可变实例」之间的本质差异。

6. 「useRef 保存最新值的模式为什么有效？」
   因为 ref 对象在多次渲染之间是同一个引用，而我们在每次渲染都用 useEffect(() => { ref.current = value; }) 把最新值写进去（这个更新不触发渲染，所以不会造成循环）。副作用（定时器/订阅）里读的是 ref.current，因此总能拿到最新值；同时副作用的依赖数组是空的，不会重建。这是 useInterval / useEventListener 这类 Hook 的标准写法。

7. 「为什么不能简单地删掉依赖来消除 ESLint 警告？」
   因为 exhaustive-deps 的警告几乎总是对的——它检测到「你在副作用里用了一个会变化的值，但没有把它列进依赖」，而这正是闭包陷阱的定义。删掉依赖只是让警告消失，bug 依然存在（甚至更隐蔽）。正确做法是：① 补齐依赖；② 如果「补齐依赖会导致副作用反复重建」不可接受，就改用 useRef 保存最新值；③ 反思这段逻辑是否本就不该放在 Effect 里。

8. 「useEffectEvent（原 useEvent）解决了什么？」
   它提供一个「永远读到最新 props/state、但引用永远稳定」的函数——正好解决「既想读最新值、又不想把它写进依赖数组」的矛盾（即闭包陷阱的核心痛点）。现状：截至 React 19 它仍处于实验阶段，生产环境应继续用「useRef 保存最新值」的模式，或自己封装一个简易的 useEvent（返回 useCallback(() => ref.current(...args), [])）。

一句话速记

闭包陷阱 = 「回调捕获了某次渲染的变量快照」——因为每次渲染都是新的函数调用，而「长期持有的回调」（定时器/订阅/异步/防抖/第三方库回调）会一直用创建它那次的变量；事件处理不会踩坑（生命周期就是本次渲染）、类组件也不会（this 是实时读取）；解法优先级是「补齐依赖 → 用 useRef 保存最新值（适合定时器/订阅，不重建副作用）→ 函数式更新（set(prev => ...)）→ useEvent 模式」；永远不要靠删依赖来消警告，那只是在掩盖 bug。