别再用 setTimeout 模拟防抖了！原生 API 才是性能天花板

在前端高频事件处理中，setTimeout 模拟防抖几乎是入门级操作——搜索框输入、按钮快速点击、窗口 resize 等场景，都能靠它减少函数执行次数。但你可能没意识到，setTimeout 天生的精度缺陷、性能损耗，让这种实现方式在高频场景下隐患重重。

而浏览器原生的 requestAnimationFrame（RAF），凭借与屏幕刷新率同步的特性，能完美替代 setTimeout 实现更高效、更流畅的防抖效果。今天我们通过实战对比，彻底告别 setTimeout 模拟防抖的短板，用原生 API 解锁性能天花板。

🔍 先看痛点：setTimeout 模拟防抖的“隐形陷阱”

先回顾一下经典的 setTimeout 防抖实现，这些隐藏的问题的你肯定踩过。

痛点1：时间精度不足，触发时机混乱

// setTimeout 实现的防抖函数
function debounce(fn, delay = 300) {
  let timer = null;
  return function(...args) {
    clearTimeout(timer);
    // 延迟 delay 毫秒执行
    timer = setTimeout(() => {
      fn.apply(this, args);
    }, delay);
  };
}

// 搜索框输入监听
const search = debounce((value) => {
  console.log('搜索：', value);
}, 300);
searchInput.addEventListener('input', (e) => search(e.target.value));

问题所在：setTimeout 的延迟时间并非精准执行——浏览器事件循环中，定时器回调会被放入宏任务队列，需等待同步代码、微任务执行完成后才会触发，实际延迟往往大于设定值。在高频输入场景下，容易出现“输入停止后，搜索逻辑延迟过久触发”的卡顿感。

痛点2：高频触发下性能损耗，引发页面卡顿

// 窗口滚动防抖（setTimeout 版）
const handleScroll = debounce(() => {
  console.log('滚动位置：', window.scrollY);
}, 100);
window.addEventListener('scroll', handleScroll);

问题所在：滚动事件触发频率极高（每秒可达数十次），即便用了防抖，setTimeout 仍会频繁创建、清除定时器。每个定时器都会占用事件循环资源，在低性能设备上容易导致页面卡顿、滚动不流畅，违背了防抖“优化性能”的初衷。

痛点3：无法适配屏幕刷新率，动画场景不兼容

// 拖拽元素防抖（setTimeout 版）
const handleDrag = debounce((pos) => {
  element.style.transform = `translate(${pos.x}px, ${pos.y}px)`;
}, 16);

问题所在：大多数浏览器屏幕刷新率为 60Hz（每 16.6ms 刷新一帧），而 setTimeout 无法精准对齐这个节奏。若设定延迟小于 16ms，回调会在同一帧内多次执行，造成资源浪费；若大于 16ms，会出现动画掉帧、不连贯的问题。

痛点4：取消逻辑繁琐，易引发内存泄漏

// setTimeout 防抖的取消逻辑
function debounce(fn, delay) {
  let timer = null;
  const debounced = function(...args) {
    clearTimeout(timer);
    timer = setTimeout(() => {
      fn.apply(this, args);
    }, delay);
  };
  // 手动添加取消方法
  debounced.cancel = () => clearTimeout(timer);
  return debounced;
}

问题所在：setTimeout 需手动维护定时器ID，取消逻辑需额外封装。若组件卸载时忘记调用 cancel 方法，定时器回调仍会执行，可能引发 DOM 操作错误或内存泄漏，尤其在单页应用中风险更高。

💡 原生 RAF 防抖：同步帧率，性能拉满

requestAnimationFrame 是浏览器专为动画/高频交互设计的原生 API，核心优势是与屏幕刷新率同步执行回调（60Hz 设备每 16.6ms 一次），无 setTimeout 的精度误差，且浏览器后台标签页时会暂停执行，大幅节省性能。

优势1：精准对齐帧率，触发时机更可控

// RAF 实现的防抖函数
function debounceWithRAF(fn, immediate = false) {
  let frameId = null;
  let isInvoked = false;

  const debounced = function(...args) {
    const context = this;
    // 取消上一帧的回调
    if (frameId) cancelAnimationFrame(frameId);

    // 立即执行版：首次触发直接执行
    if (immediate && !isInvoked) {
      fn.apply(context, args);
      isInvoked = true;
      return;
    }

    // 延迟到下一帧执行，对齐屏幕刷新率
    frameId = requestAnimationFrame(() => {
      fn.apply(context, args);
      isInvoked = false;
    });
  };

  // 取消方法：清除帧请求
  debounced.cancel = () => {
    cancelAnimationFrame(frameId);
    isInvoked = false;
  };

  return debounced;
}

核心亮点：RAF 回调始终在屏幕刷新前执行，无宏任务队列等待延迟，触发时机更精准。在搜索、滚动等场景下，既能减少函数执行次数，又能保证交互响应的流畅性，避免卡顿。

优势2：高频场景性能最优，无资源浪费

// 滚动事件防抖（RAF 版）
const handleScroll = debounceWithRAF(() => {
  console.log('滚动位置：', window.scrollY);
});
window.addEventListener('scroll', handleScroll, { passive: true });

核心亮点：RAF 会自动适配屏幕刷新率，高频事件触发时，不会像 setTimeout 那样频繁创建定时器，而是合并为每帧一次的回调执行。同时，浏览器切换到后台标签页时，RAF 会暂停执行，避免无效资源占用，性能远超 setTimeout。

优势3：动画场景无缝适配，无掉帧风险

// 拖拽元素防抖（RAF 版）
const handleDrag = debounceWithRAF((pos) => {
  element.style.transform = `translate(${pos.x}px, ${pos.y}px)`;
});

// 拖拽监听
element.addEventListener('mousemove', (e) => {
  handleDrag({ x: e.clientX, y: e.clientY });
});

核心亮点：RAF 与动画刷新节奏完全同步，拖拽、动画等场景下，元素移动会更平滑，不会出现 setTimeout 因延迟偏差导致的掉帧、卡顿问题，视觉体验更优。

优势4：取消逻辑简洁，自动避免内存泄漏

// 组件中使用 RAF 防抖（Vue/React 通用）
const debouncedFn = debounceWithRAF(() => {
  // 业务逻辑
});

// 组件卸载时取消
onUnmounted(() => {
  debouncedFn.cancel();
});

核心亮点：RAF 通过 cancelAnimationFrame 取消回调，逻辑简洁，且回调仅在当前标签页激活时执行。组件卸载时调用取消方法后，无残留定时器，从根源上避免内存泄漏。

🚀 RAF 防抖高级用法：适配多场景需求

用法1：自定义延迟倍数，灵活控制触发频率

若需调整防抖延迟（如希望 3 帧后执行，约 50ms），可通过计数控制 RAF 执行次数，实现自定义延迟。

function debounceWithRAF(fn, delayFrames = 1) {
  let frameId = null;
  let frameCount = 0;

  return function(...args) {
    const context = this;
    cancelAnimationFrame(frameId);

    frameId = requestAnimationFrame(() => {
      frameCount++;
      if (frameCount >= delayFrames) {
        fn.apply(context, args);
        frameCount = 0;
      }
    });
  };
}

// 3 帧后执行（约 50ms 延迟）
const search = debounceWithRAF((value) => {
  console.log('搜索：', value);
}, 3);

用法2：结合 RAF 实现节流，兼顾性能与响应

RAF 同样适合实现节流，相比 setTimeout 节流，能更好地对齐帧率，避免高频触发。

function throttleWithRAF(fn) {
  let isRunning = false;

  return function(...args) {
    const context = this;
    if (isRunning) return;

    isRunning = true;
    requestAnimationFrame(() => {
      fn.apply(context, args);
      isRunning = false;
    });
  };
}

// 滚动节流（每帧仅执行一次）
window.addEventListener('scroll', throttleWithRAF(() => {
  console.log('滚动位置：', window.scrollY);
}));

用法3：生产环境兜底，兼容低版本浏览器

RAF 兼容所有现代浏览器（Chrome 24+、Firefox 23+、Edge 12+），对于 IE9- 等低版本浏览器，可通过 setTimeout 兜底适配。

// 兼容版 RAF 防抖
const requestAnimFrame = window.requestAnimationFrame 
  || window.mozRequestAnimationFrame
  || (callback => setTimeout(callback, 16));

const cancelAnimFrame = window.cancelAnimationFrame
  || window.mozCancelAnimationFrame
  || clearTimeout;

function debounceWithRAF(fn) {
  let frameId = null;
  return function(...args) {
    const context = this;
    cancelAnimFrame(frameId);
    frameId = requestAnimFrame(() => {
      fn.apply(context, args);
    });
  };
}

🎯 setTimeout vs RAF 防抖 核心对比与最佳实践

维度	setTimeout 防抖	RAF 防抖
时间精度	低（受事件循环影响，延迟不准）	高（与屏幕刷新率同步，16.6ms/帧）
性能损耗	高（高频触发频繁创建/清除定时器）	低（合并回调，后台标签页暂停）
动画适配	差（易掉帧、卡顿）	优（无缝对齐动画刷新节奏）
取消逻辑	繁琐（需维护定时器ID）	简洁（cancelAnimationFrame 直接取消）
兼容性	极佳（支持所有浏览器）	良好（现代浏览器支持，低版本可兜底）
适用场景	简单低频事件，对精度要求低	高频事件、动画场景、对性能有要求

最佳实践建议

1. 优先用 RAF 防抖的场景：

   • 高频事件（滚动、拖拽、输入框实时搜索）；
   • 动画交互（元素移动、进度条加载）；
   • 对性能、流畅度有要求的场景（移动端、低性能设备）。

2. 仍用 setTimeout 防抖的场景：

   • 需精准控制延迟时间（如 1000ms 后执行），且对帧率无要求；
   • 需兼容 IE9 及以下低版本浏览器，且无法添加兜底方案。

3. 生产环境进阶方案：

   • 高频场景用 RAF 防抖/节流，搭配 passive: true 优化滚动性能；
   • 需精准延迟时，用 RAF 计数实现自定义延迟，兼顾精度与性能；
   • 低版本浏览器兜底时，优先使用 setTimeout 适配，避免功能失效。

✨ 写在最后

setTimeout 模拟防抖是入门级方案，但在高频场景、动画交互中，其精度和性能缺陷会被无限放大。而 RAF 作为浏览器原生的高性能 API，天生为高频交互和动画设计，既能实现防抖的核心需求，又能保证交互流畅性和性能最优。

从今天开始，把代码里的 setTimeout 防抖，逐步替换为 RAF 实现——尤其是在移动端和动画场景中，你会明显感受到页面性能和交互体验的提升。用对原生 API，才能在不增加代码复杂度的前提下，实现“降本增效”的优化目标。