JS 防抖和节流到底该用哪个：从输入搜索框说起

输入搜索框每敲一个字符就发一次请求，滚动时监听函数一秒触发几十次——这种情况到底该用防抖还是节流？一句话结论：防抖适合"最后一次操作停下后才执行"，节流适合"固定时间间隔内最多执行一次"。把这两者用反了，要么请求狂发把接口打爆，要么页面卡顿用户以为失灵。

你大概率在两种场景踩过坑：一个是搜索框联想，每输入一个字就向后端要一次建议词；另一个是页面滚动监听，想做"滚动到某位置再加载更多"，结果滚动事件密集触发，函数被调用成百上千次。这两类问题看着像，但解法完全不同。今天这篇文章，编程狮就用最通俗的方式，把防抖和节流的区别、怎么实现、什么时候用谁一次讲透，并给出可直接运行的代码和验证方法。

一、先看结论：什么时候用谁

防抖（debounce）的核心动作是"等一等"：事件连续触发时，它不立刻执行，而是等这段时间没有新触发了，才执行最后一次。最典型的例子就是搜索框——你连续打字，它只在你停下来（比如停了 300 毫秒）才发请求。

节流（throttle）的核心动作是"卡节奏"：无论事件触发多频繁，它都保证在一个固定时间窗口内只执行一次。最典型的例子是滚动加载——你一直滚，它每 200 毫秒最多执行一次回调，不会多。

💡 小提示：判断口诀很简单——"只关心最终结果、中间过程不重要"用防抖；"过程也要按节奏采样"用节流。想系统了解事件机制，可以先看 JavaScript 教程。

适用边界上要记牢：防抖适合"结果型"操作，比如搜索联想、表单校验、窗口 resize 后重算布局；节流适合"过程型"操作，比如滚动加载、拖拽定位、游戏帧循环、按钮防连点。如果你的需求是"用户一停就要结果"，选防抖；如果是"过程中要持续、稳定地响应"，选节流。两者都只是控制执行频率，不改变函数本体逻辑。

二、防抖与节流各是什么

防抖的本质是一个定时器。每次事件触发，它先把上一个还没执行的定时器清掉，再重新计时。只要你在计时窗口内又触发了，上一个就被取消，永远等不到执行。只有当你彻底停下来，定时器才真正到点执行。

节流的本质是一个"开关 + 时间戳"。它记录上一次执行的时间，新事件来了先问：距离上次执行够不够一个窗口？不够就直接忽略；够了就执行，并更新时间戳。这样无论你触发多猛，单位时间内的执行次数被强行压平。

两者都是为了"降低高频事件的执行频率"，但压的方式相反：防抖把多次合并成最后一次，节流把多次均匀摊到时间轴上。对照 JavaScript 速查手册 能把语法细节查得更准。性能层面，防抖在"持续输入"时几乎零执行（最省），但最后一次有等待延迟；节流执行次数可预测，适合做平滑动画和限流统计。

三、两种实现与取舍

下面给一份可直接运行的防抖实现。注意 timer 必须放在闭包外，否则每次调用都新建定时器，防抖就失效了：

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

const search = debounce((kw) => {
  console.log("发起搜索请求:", kw);
}, 300);

search("p");
search("py");
search("pyt");
// 实际输出：只打印一次 "发起搜索请求: pyt"

节流实现可以这样写，用时间戳判断是否到窗口：

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

const onScroll = throttle(() => {
  console.log("滚动采样一次");
}, 200);

取舍上，防抖在"输入建议"里体验更好，因为用户连续输入时不应该打扰后端；节流在"滚动、拖拽、游戏帧"里更稳，因为它保证有规律地执行，不会像防抖那样在用户一直操作时不触发任何动作。需要边写边验证语法时，可以直接用 JavaScript 在线运行 跑一遍。

四、边界与常见失败

防抖有一个常见失败点：首次触发永远等一个完整窗口。如果用户只操作一次，也要等 wait 毫秒才响应，体感变慢。解决办法是加 immediate 选项，让第一次立即执行、后续走防抖。

节流也有坑：上面基于时间戳的写法，在最后一次触发如果没到窗口边界，那次会被丢掉。想要"最后一次也补执行"，得用"时间戳 + 定时器"混合版，在窗口末尾用 setTimeout 兜底补一次。

另一个边界是 this 和参数。上面用 fn.apply(this, args) 保留了调用上下文；如果你用箭头函数包一层却忘了 apply，回调里的 this 会指向错误对象。Node 环境下的事件循环和浏览器略有差异，可参考 Node.js 教程 做对照。

⚠️ 注意：防抖和节流都只是"控制执行频率"，不会改变函数本身的逻辑。如果回调里有重量级 DOM 操作，再节流也救不了根本性能问题，该做虚拟列表还得做。失败排查时，先确认定时器是否在同一闭包共享，再确认回调有没有被框架（如 React 严格模式）重复包装。

五、用输入输出验证结果

你可以用本地运行环境连续调用 throttle 十次，预期在 1 秒内只看到约 5 次（窗口 200 毫秒）输出，而不是 10 次。如果看到 10 次，说明 last 没被正确更新，通常是闭包变量放错了位置。

防抖的验证更简单：连续调用 debounce 三次，预期只有最后一次的参数被打印。如果三次都打印，基本是 clearTimeout 没生效或 timer 不是闭包共享变量。Angular 系的双向绑定里也常封装这两类逻辑，参考 AngularJS 教程 能看清框架层的节流封装思路。

六、工程化：别重复造轮子

实际项目里，直接用成熟库更稳。lodash 提供了 debounce 和 throttle，并且 debounce(fn, wait, { maxWait }) 能用 maxWait 保证"最迟多久一定执行一次"，避免防抖在持续触发时永远不执行的缺陷。React 生态里有 useDebounce、useThrottle 等 Hook，但要注意它们返回的通常是值或函数，且依赖项变化会重置计时。

配置建议：搜索框联想 wait 取 250–400 毫秒；滚动加载取 150–250 毫秒；按钮防连点取 800–1000 毫秒。数值越大越省资源，但响应越迟钝，按场景权衡。

总结

防抖和节流都是高频事件的"降频器"，但机制相反：防抖合并成最后一次，节流按固定节奏采样。搜索框、表单校验这类"只关心结果"的场景用防抖；滚动加载、拖拽、游戏循环这类"过程要按节奏"的场景用节流。实现时务必把定时器或时间戳放在闭包里共享，否则降频会完全失效。工程上优先复用 lodash，并注意 maxWait 与 immediate 两个选项的边界。

常见问题

Q：防抖和节流能一起用吗？

能。典型场景是搜索框既要防抖（停下才发请求）又要节流（避免极端情况下请求过密），可以先用防抖包一层、内部再节流，或者直接选用 lodash 的 debounce(fn, wait, {maxWait})，用 maxWait 保证最迟多久一定执行一次。

Q：为什么我的防抖完全没生效？

最常见原因是 timer 变量写在返回函数内部，每次调用都重新声明，导致 clearTimeout 清的是上一轮的新定时器。把 let timer = null 提到外层闭包，让每次调用共享同一个定时器即可。

Q：滚动监听用防抖还是节流？

用节流。滚动是持续过程，如果用防抖，用户一直滚就一直不触发，体验像失灵。节流能保证每 200 毫秒采样一次，既流畅又不卡。

延伸学习

• JavaScript 原生模块
• JS 防抖与节流怎么选
• Javascript 开发资源