React useDebounce Hook问题：移入setTimeout到状态更新函数后失效

问题重现 #

原正常防抖Hook代码 #

import React from "react";

const TIME_MS = 2000;

const useDebounce = () => {
  const [, setTimerId] = React.useState<NodeJS.Timeout>();

  return React.useCallback((func: () => void) => {
    const newTimerId = setTimeout(func, TIME_MS);
    setTimerId(oldTimerId => {
      clearTimeout(oldTimerId);
      return newTimerId;
    });
  }, []);
};

修改后失效的代码 #

import React from "react";

const TIME_MS = 2000;

const useDebounce = () => {
  const [, setTimerId] = React.useState<NodeJS.Timeout>();

  return React.useCallback((func: () => void) => {
    setTimerId(oldTimerId => {
      const newTimerId = setTimeout(func, TIME_MS);
      clearTimeout(oldTimerId);
      return newTimerId;
    });
  }, []);
};

核心原因分析 #

修改后的代码失效，本质是React状态更新的异步特性和定时器创建时机错位导致的：

1. 定时器延迟起点偏离预期
   原代码中，每次调用防抖函数时会立即创建新定时器，延迟时间从用户触发操作的瞬间开始计算，随后通过setTimerId的回调清除上一次的旧定时器。无论React何时处理状态更新，新定时器的延迟周期都严格对齐用户最后一次操作的时刻，符合防抖的核心逻辑。

   而修改后的代码把定时器创建逻辑移入setTimerId的回调中，这个回调的执行时机由React控制，属于异步批量执行（比如在事件处理结束后、下一次渲染前才会触发）。这就导致定时器的创建时间被推迟，延迟周期从React执行回调的时刻开始计算，而非用户操作的时刻。极端场景下，如果React批量更新被延迟，会出现用户操作后很久才创建定时器，函数触发时间完全不符合预期。

2. 旧定时器无法及时拦截
   当用户短时间内多次调用防抖函数时，多个setTimerId的回调会进入队列等待执行。在这些回调执行前，上一次回调创建的定时器可能已经到达延迟时间并触发，此时再清除旧定时器已经无效，直接导致防抖失效，函数被多次执行。

3. 批量更新下的定时器时间线混乱
   即使React按顺序执行函数式状态更新的回调，由于所有定时器都在同一批回调中创建，它们的延迟起点都是回调执行的时刻，而非用户操作的时间点。比如连续三次调用防抖函数，三个回调会集中执行，创建的定时器被依次清除，最后保留的定时器延迟周期从回调执行时刻算起，完全违背了“最后一次操作后延迟执行”的防抖设计初衷。

总结 #

防抖的核心是在用户最后一次操作后立即启动延迟定时器，并同步清除之前未触发的定时器。原代码完全贴合这个逻辑，而修改后的代码将定时器创建移入异步的状态更新回调，打乱了定时器的时间线，最终导致防抖功能失效。

内容的提问来源于stack exchange，提问作者Lorenzo