你有没有遇到过这样的场景？
- 用户在搜索框疯狂打字，每敲一个字符就发一次请求；
- 页面滚动时监听
scroll事件，结果函数一秒执行上百次； - 点击按钮太快，接口被重复提交，导致数据错乱……
这些问题看似简单，实则暴露了前端开发中一个核心问题：如何控制高频事件的执行频率？
今天我们就来深入聊聊两个经典解决方案 —— 防抖（Debounce）和节流（Throttle）。它们不仅是性能优化的利器，更是理解 JavaScript 闭包、函数式编程思想的绝佳案例。
一、从一个问题开始：为什么需要防抖和节流？
假设我们正在做一个百度搜索建议功能：
<input type="text" id="search" placeholder="请输入关键词">
document.getElementById('search').addEventListener('keyup', function(e) {
ajax(e.target.value); // 每次按键都发起请求
});
看起来没问题？但现实是：
- 用户输入 “react” 四个字母，会触发 4 次请求；
- 如果网络延迟高，可能先收到
rea的响应，再收到re的，造成界面闪烁； - 服务器压力陡增，用户体验反而下降。
这就像让厨师做一道菜，你一边切菜一边喊“做好了吗”，他只能不停地停下来看你有没有切完——效率极低。
于是我们需要一种机制：等用户真正停下来再执行任务，或者 保证一定时间内只执行一次。
这就是 防抖 和 节流 存在的意义。
二、什么是防抖？—— 只执行最后一次
1. 核心思想
防抖（Debounce）：当事件被频繁触发时，只执行最后一次。
你可以把它想象成电梯的关门逻辑：
虽然按钮按了很多次，但电梯只会等最后一个人进来后，延迟几秒才关门。
2. 实现原理
我们借助 定时器 + 闭包 来实现：
function debounce(fn, delay) {
let timer = null; // 闭包变量，保存定时器 ID
return function(...args) {
const that = this; // 保存 this 上下文
if (timer) clearTimeout(timer); // 清除之前的定时器
timer = setTimeout(() => {
fn.apply(that, args);
}, delay);
}
}
3. 关键点解析
| 技术点 | 解释 |
|---|---|
let timer = null | 利用闭包保存状态，外部无法干扰 |
clearTimeout(timer) | 取消上一次未执行的任务 |
setTimeout | 延迟执行，等待用户“安静下来” |
fn.apply(this, args) | 正确绑定上下文并传递参数 |
4. 使用示例
const input = document.getElementById('debounce');
const debounceAjax = debounce(ajax, 1000);
input.addEventListener('keyup', function(e) {
debounceAjax(e.target.value);
});
function ajax(content) {
console.log('发送请求:', content);
}
此时无论用户打了多少字，只要间隔小于 1 秒，就不会发送请求；只有当他停顿超过 1 秒，才会真正执行。
适用场景：
- 搜索建议
- 表单自动保存
- 实时预览（如 Markdown 编辑器）
三、什么是节流？—— 固定频率执行
1. 核心思想
节流（Throttle）：无论事件触发多频繁，保证每隔一段时间执行一次。
类比游戏中的射速限制：
即使你狂点鼠标，子弹也只能每 500ms 射出一发。
2. 实现方式（时间戳 + 定时器结合）
function throttle(fn, delay) {
let last = 0; // 上次执行时间
let defertimer = null; // 延迟定时器
return function(...args) {
const that = this;
const now = +new Date(); // 当前时间戳
if (last && now < last + delay) {
// 还没到执行时间，设置延迟执行
clearTimeout(defertimer);
defertimer = setTimeout(() => {
last = now;
fn.apply(that, args);
}, delay);
} else {
// 时间到了，立即执行
last = now;
fn.apply(that, args);
}
}
}
3. 执行流程图解
用户连续触发事件：
[ keyup ] [ keyup ] [ keyup ] [ keyup ] ...
│ │ │ │
▼ ▼ ▼ ▼
100ms 200ms 300ms 400ms （假设 delay=500ms）
前几次都不满足条件 → 不执行
直到第 600ms 第一次执行 → 更新 last
后续每 500ms 至少执行一次
注意：这里用了“补尾”策略，在最后一次触发后仍确保执行一次，避免遗漏。
4. 使用示例
const input = document.getElementById('throttle');
const throttleAjax = throttle(ajax, 500);
input.addEventListener('keyup', function(e) {
throttleAjax(e.target.value);
});
即使用户飞快打字，最多每 500ms 发送一次请求。
适用场景：
- 滚动加载（infinite scroll）
- 窗口 resize 监听
- 按钮防连点（submit 防重复提交）
四、防抖 vs 节流：本质区别在哪？
| 对比项 | 防抖（Debounce） | 节流（Throttle） |
|---|---|---|
| 执行时机 | 最后一次触发后执行 | 固定间隔执行 |
| 触发频率 | 高频 → 只执行一次 | 高频 → 匀速执行 |
| 适用场景 | 用户输入结束才处理 | 持续动作中定期处理 |
| 类比比喻 | 电梯等人都上齐再关门 | 游戏枪械有固定射速 |
| 是否漏执行 | 可能中途完全不执行 | 保证周期性执行 |
总结一句话：
- 防抖 是“冷静期”模式：你要闹就闹够，等你安静了我再理你。
- 节流 是“限流阀”模式：不管你闹多凶，我按我的节奏来。
五、闭包在这里扮演什么角色？
这两个函数之所以能工作，核心依赖于 闭包（Closure）。
回顾一下防抖代码中的关键变量：
function debounce(fn, delay) {
let timer = null; // ← 这个变量被内部函数引用
return function(...args) {
if (timer) clearTimeout(timer);
timer = setTimeout(...); // 内部使用 timer
}
}
尽管 debounce 函数已经执行完毕，但由于返回的函数仍然引用着 timer，所以它不会被垃圾回收 —— 这就是闭包的力量。
闭包在此的作用：
- 保存私有状态（如
timer,last） - 避免全局污染
- 实现数据封装，类似“私有变量”
这也是为什么说：“函数是一等公民，闭包是它的灵魂伴侣”。
六、常见误区与最佳实践
错误写法：箭头函数丢失 this
return (...args) => {
fn(...args); // this 指向外层，不是事件绑定对象！
}
正确做法：保留原始上下文
return function(...args) {
fn.apply(this, args); // this 指向 input 元素
}
支持传参的小技巧：使用 ...args
debounceAjax(e.target.value); // 参数通过 arguments 透传
利用剩余参数和 apply，完美支持任意参数传递。
不要忘记清除定时器
尤其是在组件卸载时（React/Vue 中），应手动清空 timer，防止内存泄漏。
// Vue 示例
beforeUnmount() {
if (this.debouncedHandler) {
const timer = this.debouncedHandler.timerRef;
if (timer) clearTimeout(timer);
}
}
七、总结：什么时候该用哪个？
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 用户输入搜索词 | 防抖 | 只关心最终结果 |
| 页面滚动加载更多 | 节流 | 滚动过程中需定期检查位置 |
| 窗口 resize 改变布局 | 节流 | 需要在变化中持续响应 |
| 表单实时校验 | 防抖 | 输入完成后再验证更合理 |
| 提交按钮防重复点击 | 节流 or 防抖均可 | 控制点击频率即可 |
结语：小技术，大智慧
防抖和节流看起来只是加了个 setTimeout，但背后涉及的知识却非常丰富：
- 闭包的应用
- this 指向的处理
- 函数式编程思想（高阶函数）
- 性能优化意识
- 用户体验考量
它们不像框架那样炫酷，但却像空气一样无处不在。掌握它们，不仅是为了写出更好的代码，更是为了培养一种 对细节的敬畏之心。
下次当你看到输入框或滚动条时，不妨多问一句：
“这个事件真的需要每次都响应吗？”
也许答案，就是一个更优雅的用户体验。
