防抖与节流是什么？怎么实现？

防抖与节流是前端应对高频事件（如输入、滚动、拖拽）的核心性能优化技术：防抖通过重置定时器确保只在用户操作完全停止后执行一次，适用于搜索联想等需“静默等待”的场景；节流则通过时间戳或定时器强制限制执行频率，保证每N毫秒最多执行一回，更适合滚动监听等需持续响应的交互。二者看似简单，实则极易因忘记清除定时器、丢失this上下文、参数传递错误或框架中重复创建而引发严重bug——真正稳定落地的关键，在于精准的定时器管理、严谨的闭包封装以及与React/Vue等框架生命周期的深度协同。

防抖（debounce）解决什么问题？

用户连续触发事件（比如 input、resize、scroll）时，你只想在“最后一次操作结束后过一段时间”再执行处理逻辑。典型场景是搜索框输入后发请求，避免每敲一个字就调一次 API。

关键点：重置定时器，只保留最后一次的延迟执行机会。

• 每次触发都清除前一个 setTimeout，重新设新定时器
• 必须保存上一个 timer 的引用，否则无法清除
• 函数内部要能访问到原始参数，推荐用 ...args + apply 或箭头函数闭包

function debounce(fn, delay) {
  let timer = null;
  return function(...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

节流（throttle）适合什么场景？

高频事件需要“有节制地执行”，比如 scroll 中更新滚动位置、拖拽时计算坐标。你希望它每 N 毫秒最多执行一次，而不是等停了才执行（防抖的逻辑）。

核心区别：节流关注“执行频率上限”，不是“等待静默期”。有两种主流实现方式——时间戳版（立即执行）和定时器版（延迟执行），前者更常用。

• 时间戳版：记录上次执行时间，当前时间减去上次时间 ≥ delay 才执行
• 定时器版：用 setTimeout 控制下一次可执行时机，期间忽略所有调用
• 注意 this 和参数传递，同样要用 ...args 和 apply

function throttle(fn, delay) {
  let lastTime = 0;
  return function(...args) {
    const now = Date.now();
    if (now - lastTime >= delay) {
      fn.apply(this, args);
      lastTime = now;
    }
  };
}

为什么不能直接用 setTimeout 而不清理？

防抖漏掉 clearTimeout 是最常见错误，会导致多个定时器同时存在，最终一堆重复执行；节流如果没做时间比对或定时器锁定，也会失控执行。

• 防抖中不 clearTimeout(timer) → 多次触发产生多个并行定时器 → 最后一个未必是“最后触发”的结果
• 节流中不记录 lastTime 或不控制 setTimeout 状态 → 可能每帧都执行，失去限频意义
• 没绑定正确的 this → 回调里取不到组件实例或 DOM 元素，尤其在 class 方法中使用时

实际用的时候要注意哪些细节？

防抖和节流函数本身是纯函数，但挂载到事件监听器时容易出错。比如 React 函数组件里反复创建新防抖函数，导致监听器地址变化，事件被重复绑定或失效。

• 在 React 中，用 useCallback 缓存防抖/节流函数，依赖项包含 fn 和 delay
• Vue 3 的 setup 中，也建议在 onMounted 里定义并绑定，避免每次渲染重建
• 原生 JS 绑定时，别写成 element.addEventListener('input', debounce(handleInput, 300)()) —— 多了一对括号，直接执行了
• 移动端 touchmove 触发极快，delay 设太小（如 16ms）可能还是压不住，建议 ≥ 50ms

防抖和节流看着简单，真正稳定跑在线上，关键是定时器管理、上下文绑定、以及框架生命周期里的复用控制。漏掉任何一个，都可能让“优化”变成“bug 来源”。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~