1. 先搞清楚这两个函数到底在解决什么问题
如果你写前端写过一段时间，大概率遇过这种场景：页面绑定了 resize、scroll、mousemove、input 这类高频事件，回调函数被触发的频率能到每秒几十次甚至上百次，但真正收取的事件信息变化频率却没那么高。这时候如果回调里塞了重排、请求、缓存计算这类成本高的操作，浏览器就很容易出现卡顿、抖动，甚至直接白屏。说得直白一点，不是电脑不行，是代码在“干无效功”。
防抖函数（debounce）和节流函数（throttle）就是专门用来解决这类问题的两个工具，核心目标都是“减少回调函数的实际执行次数”，但两者的策略思路完全不同，适用场景也不一样。
先看一组直观数字。一个常规的 window.scroll 事件，拖动一下滚动条可能触发 20 到 30 次回调，如果每次回调里都执行一次 DOM 查询或渲染计算，一秒钟还没划完一个屏幕，页面就明显掉帧了。更夸张的是搜索引擎输入框，用户每敲一个字母就触发一次搜索请求，网络慢的时候请求对不上号，前端还要做竞态处理。类似这些问题，本质都是“事件触发频率”和“业务处理成本”不匹配。
防抖的思路是“延迟合并”。我不管用户触发了多少次，我只在最后一次触发之后等待一段时间，如果这段时间里没有新触发，才真正执行函数。电梯上有人不停按开门键，电梯就这么等着，直到确定没人再进才关门，这就是防抖。好处是逻辑简单、不容易误触发，缺点是如果用户一直不停触发，函数可能永远不执行，这也就是为什么防抖常用于“连续输入结束之后再搜索”这种场景。
节流则是“限定频率”。无论用户触发多少次，函数在固定的时间间隔内最多执行一次。比作公交车发车更合适：起点站每隔十分钟发一班，不管站台来了多少人，车到了点就开，没到点就等。好处是保证执行节奏稳定，不会无限拖延，但每个周期内第一次触发和最后一次触发的时间点处理不好，容易出现边界行为差异。
你可能会问，两个东西听起来差不多，具体到代码里到底怎么写？这就要分别从实现和原理入手了。实际开发里直接拿 Lodash 的 debounce 和 throttle 来用当然省事，但如果不理解它们的行为边界，很容易在排查问题的时候一头雾水。所以我更建议自己手写一遍，把机制吃透，再决定是自研还是引入工具库。
2. 防抖函数：一步步从基础版写到生产可用版
2.1 第一版防抖：高频触发后延迟执行
防抖的核心机制，就是每次事件触发时，把上一次设置的定时器清掉，然后重新设置一个新的定时器。这样只有最后一次触发能“活”到计时结束。
function debounce(fn, delay = 300) { let timer = null; return function (...args) { if (timer) { clearTimeout(timer); } timer = setTimeout(() => { fn.apply(this, args); timer = null; }, delay); }; }注意这里有个关键点：clearTimeout之后timer变量本身还有值，没有被置空，但不影响后续逻辑。要么在定时器执行后把timer置为null，要么在判断时直接以if (timer !== null)作为依据。我习惯在定时器回调里顺手置空，方便后续实现cancel和flush的时候状态更清晰。
调用方式也很直接：
const handleResize = debounce(() => { console.log('窗口尺寸变化结束后的最终回调'); }, 300); window.addEventListener('resize', handleResize);这个版本能满足入门演示和简单场景，但拿到生产环境就会发现几个问题：第一，如果用户持续触发事件超过几秒，回调可能一直不执行，界面反馈会显得“迟钝”；第二，忘记清理定时器的话，页面卸载后回调仍然有可能执行；第三，很多业务需要“第一次点击立即执行”或者“手动取消本次等待”，这个版本统统做不到。
2.2 支持立即执行、取消与主动刷新
Lodash 的 debounce 支持leading和trailing配置，分别代表“在延迟开始前立即执行一次”和“在延迟结束后执行一次”。这个设计很实用，我用一个日常案例解释一下：表单里的“保存”按钮，如果只做防抖，用户连点三次，第一次点击没有立即反馈，保存真正发生是在最后一次点击后的 300ms，体验上就会觉得“我点了怎么没反应”。如果配置了leading: true，第一次点击马上执行，后面的连点全部被忽略，就自然起到了“防止重复提交”的作用。
下面是我经常使用的一个经典实现：
function debounce(fn, delay = 300, immediate = false) { let timer = null; let result; let lastArgs; let lastThis; function invoke() { if (timer) { clearTimeout(timer); timer = null; } result = fn.apply(lastThis, lastArgs); } function debounced(...args) { lastArgs = args; lastThis = this; if (immediate && !timer) { // 如果尚未有定时器，说明距离上一次触发已经超过 delay，立即执行 result = fn.apply(this, args); } else { if (timer) { clearTimeout(timer); } timer = setTimeout(() => { timer = null; if (!immediate) { result = fn.apply(this, args); } }, delay); } return result; } debounced.cancel = function () { if (timer) { clearTimeout(timer); timer = null; } }; debounced.flush = function () { if (timer) { clearTimeout(timer); invoke(); } }; return debounced; }这里面的cancel和flush是生产环境必备的两个能力。我在排查线上问题的时候，见过很多次因为组件卸载时没有 cancel，导致异步回调去访问已经被卸载的 DOM 数据，产生难以追踪的内存泄漏或者“幽灵请求”。正确的操作是在组件的卸载生命周期里调用一次 cancel：
useEffect(() => { const debouncedSave = debounce(() => { saveDraft(); }, 1000); window.addEventListener('scroll', debouncedSave); return () => { debouncedSave.cancel(); window.removeEventListener('scroll', debouncedSave); }; }, []);2.3 有最大等待时间的防抖才是“完整版”
防抖函数有一个先天缺陷：连续操作如果一直不停止，回调函数就永远没有机会执行。比如用户一直在输入框里打字，文字从 1 个字打到 500 个字，中途几乎没有停顿超过 300ms，防抖函数就一直重置定时器，搜索请求迟迟发不出去。
Lodash 解决这个问题的方案是maxWait配置项：在防抖延迟的基础上，额外设置一个最大等待时间，即便用户不断触发，也保证每过maxWait毫秒至少执行一次。
这个逻辑背后的原理很有意思：如果我把防抖的maxWait设为 5000ms，delay 设为 300ms，实际上就已经无限接近节流的思想了。准确地说，throttle 可以看作一个maxWait等于wait时间、延迟时间也等于wait的特殊防抖。理解了这一点，再看 Lodash 文档里那个“throttle 就是带 maxWait 的 debounce”的说法，就不会觉得玄乎了。
如果你不打算引入 Lodash，想自己实现maxWait版本，核心做法是把“上一次执行时间”记录下来，在每次触发时判断“当前时间减去上次执行时间是否超过了 maxWait”，超过就直接执行并重置。这个能力在日常业务里非常实用，建议手写一次加深印象。
3. 节流函数：时间戳方案和定时器方案怎么选
3.1 时间戳版本：保证首次触发立即执行
节流实现一般有两种主流方案，分别对应不同的边界行为。先说时间戳方案。
function throttle(fn, interval = 300) { let lastTime = 0; return function (...args) { const now = Date.now(); if (now - lastTime >= interval) { lastTime = now; fn.apply(this, args); } }; }这段代码的逻辑很直白：每次触发时，检查当前时间距离上一次实际执行是否已经超过了规定的间隔，如果超过了，就执行并更新时间戳，否则跳过。这里的lastTime初始化为 0，意味着第一次触发时now - lastTime一定大于 interval，所以首次触发会立即执行。
时间戳版本的优点是实现简单、响应灵敏，第一下触发就能看到效果。缺点是最后一次触发如果落在间隔区间内，会被直接吞掉，导致“尾巴丢了”。比如用户快速点击“加载更多”按钮，最后一次点击后间隔内还有新数据没加载出来，体验就不好。另外，它不能保证在停止触发后补上最后一次执行。
3.2 定时器版本：保证间隔结束后补执行
定时器版本的节流思路是，用定时器来控制执行节奏。第一次触发时设置一个定时器，间隔结束之后执行函数，然后把定时器置空；在这个间隔内，后续触发全部忽略，直到定时器执行完毕，下一次触发才能再次开启定时器。
function throttle(fn, interval = 300) { let timer = null; return function (...args) { if (!timer) { timer = setTimeout(() => { fn.apply(this, args); timer = null; }, interval); } }; }这个版本的特性正好和时间戳版本互补：首次触发不会立即执行，而是等 interval 结束之后才执行；但是一旦触发停止，它会在停止后的 interval 时刻补上最后一次执行。对于“滑动结束之后要统计最终位置”这类场景，这个行为更友好。
实际业务中，很多需求其实是“首次要快、最后一次也不能丢”。比如滚动加载列表，如果用户连续快速滚动，需求是尽量快地加载新内容，同时滚动停止后要把最后的加载请求补上。这种时候单独用时间戳版本或定时器版本都有点别扭，就需要把两者组合一下。
3.3 组合版本：首尾兼顾，通用性更强
组合版本的思路是：用时间戳记录上次执行时间，用定时器处理“尾部补执行”。每次触发时，先计算距离上次执行的时间差，如果超过 interval 就立即执行并更新时间戳；如果没有超过，就清除之前的定时器，重新设置一个定时器，在剩余时间结束后执行最后一次调用。
function throttle(fn, interval = 300) { let timer = null; let lastTime = 0; let lastArgs; let lastThis; function run() { lastTime = Date.now(); timer = null; fn.apply(lastThis, lastArgs); } return function (...args) { const now = Date.now(); const remaining = interval - (now - lastTime); lastArgs = args; lastThis = this; if (remaining <= 0) { // 等待时间已过，立即执行并清掉定时器 if (timer) { clearTimeout(timer); timer = null; } run(); } else if (!timer) { // 剩余时间结束后执行最后一次触发 timer = setTimeout(run, remaining); } // 如果 timer 已存在，说明上一次的尾部补执行还没到时，就不做任何事 }; }注意这里有个容易写错的细节：如果remaining <= 0且timer存在，一定要把定时器清掉再执行，否则会出现“执行了一次，定时器又补了一次”的双重重叠问题，整体批次就会错乱。我每次手写组合版本时，都会特意把clearTimeout和timer = null放在执行前，然后用run函数统一处理时间戳更新和定时器清理。
如果你不想手写这么复杂，又有压测场景，可以退一步用requestAnimationFrame做特殊节流。requestAnimationFrame天然按照浏览器帧率调度回调，约为 16.7ms 一次，适合动画、滚动推进这类视觉相关逻辑，但它不适合频率需要精确控制的业务请求，因为帧率会受显示屏和页面复杂度影响。
4. 防抖节流到底怎么选：一张表理清边界
4.1 基于触发和执行的时机对比
与其死记“输入用防抖，滚动用节流”，不如从行为目的出发来判断。我先给出一张对比表，方便你直接对照业务需求选型。
| 对比维度 | 防抖（debounce） | 节流（throttle） |
|---|---|---|
| 核心思想 | 连续触发合并为一次，取最后一次 | 固定周期内最多执行一次 |
| 第一次触发 | 默认不立即执行（可配置 leading） | 时间戳方案立即执行，定时器方案延迟执行 |
| 停止触发后 | 延迟结束后会执行最后一次 | 时间戳方案不补，定时器方案会补 |
| 持续触发时 | 可能一直不执行，直到停手 | 按固定频率稳定执行 |
| 适用场景 | 搜索联想、表单校验、窗口尺寸变化后重新布局、自动保存 | 滚动加载、鼠标移动、拖拽、按钮防连点、游戏中的射击频率 |
| 典型工具库实现 | Lodash debounce | Lodash throttle |
判断口诀也很简单：如果你的需求是“等用户操作完我再去处理”，选防抖；如果你的需求是“用户操作过程中我需要持续处理，但频率不能太高”，选节流。
4.2 从实际问题反推正确的选择
举一个具体的例子。搜索框输入联想，需求是“用户停止输入约 300ms 后再发请求”。这明显是防抖。但如果改成“用户在输入过程中也要实时返回推荐结果，每 200ms 最多请求一次”，这就变成节流了。同一个输入框，需求一变，选型就得跟着变。
再举例。无限滚动加载列表，用户快速滚动到底部，如果每触发一次 scroll 就请求一次，服务器扛不住；如果等用户完全停止滚动才加载，用户盯着空白区域等待又会焦虑。这种场景显然要节流，“每 500ms 检查一次滚动位置，接近底部就加载下一页”，既保证节奏，又不会漏掉持续滚动的场景。
还有一个很容易混淆的场景是按钮点击防连点。用户手抖双击“提交订单”，前端应该只发一次请求。防抖的做法是等 300ms 没第二次点击才提交，但这意味着用户点击后要等 300ms 才有反馈，体验不理想。更好的方案是用节流的 leading 版本或自定义的“首次立即执行防抖”，代码如下：
const submitOrder = debounce(() => { api.submitOrder(orderInfo); }, 300, true); // 提交按钮点击后立即执行，300ms 内的重复点击无效 btn.addEventListener('click', submitOrder);注意这个 third 参数就是 immediate，也就是leading效果。它兼顾了“立即响应”和“防止连点”两个诉求。这是我在实际项目里最常用的写法之一，建议记下来。
4.3 防抖和节流的深层关系
理解到这一层，你会发现防抖和节流其实不是两个截然不同的东西。如果给防抖函数加上maxWait配置，它就能在持续触发场景下保证至少每段时间执行一次，从而让防抖也能起到“稳定执行”的作用。反过来，Lodash 的 throttle 本质上就是debounce(fn, wait, { maxWait: wait })，它调用的是同一个 debounce 函数。
这也解释了为什么很多团队最终只引入 Lodash 或者自研一个带maxWait的 debounce 函数，因为只要这一个函数能力完整，就能覆盖节流的所有场景。不过在代码可读性上，显式用throttle更直观，别人看代码一眼就知道你要表达什么语义，所以从协作角度出发，我建议不要过度追求底层统一，保持语义清晰更重要。
5. 实战过程中的常见问题和排查技巧
5.1 this 指向丢失、arguments 透传异常
很多人第一次自己写防抖函数时，容易犯一个错误：在定时器回调里直接调用fn，没有把闭包保存的context和args透传进去。这样会导致回调内部的this指向window或undefined（严格模式下），拿不到当前元素、组件实例等关键数据。
我的建议是，在返回的函数里先保存const context = this和const args = arguments，然后在定时器回调里用fn.apply(context, args)调用。如果你用的是箭头函数，箭头函数本身没有自己的arguments和this，所以保存动作要放在外层普通函数里。这个细节虽然简单，但能避免生产环境里很多难以定位的“事件处理函数里 this 不对”的问题。
5.2 组件卸载后定时器回调还在执行
这恐怕是我在社区里看到最多的问题之一。React 组件卸载了、Vue 组件销毁了，防抖或节流的定时器却还挂着，回调里又访问了组件的 state 或 DOM，轻则报错，重则导致旧数据被覆盖到新页面上。
解决方法是统一约定：所有产生定时器的工具函数，都必须暴露cancel方法，并在组件卸载时调用。如果你用的是 Lodash，debounce返回的函数本身就带cancel、flush方法，直接用就行。如果你自研，一定要记得把 cancel 挂载到返回的函数上。
Vue 3 的写法示例：
<script setup> import { onBeforeUnmount } from 'vue'; function handleInput() { // 输入处理 } const debouncedHandleInput = debounce(handleInput, 300); onBeforeUnmount(() => { debouncedHandleInput.cancel(); }); </script>5.3 节流后“最后一次触发”被丢失
如果你用的是时间戳版节流，然后发现用户快速操作时，最后几次操作没有生效，这不是函数写错了，而是时间戳版本身的策略缺陷。解决方式有两种：一是换成定时器版或首尾兼顾的组合版本；二是在业务逻辑上做兜底，比如滚动到底部时再判断一次是否还有剩余数据，主动触发加载。
我遇到过一个实际案例：一个“加载更多”按钮，用户快速点了几次，前两次立即触发了请求，第三次因为间隔不够被跳过，而用户期待的是第三次也必须触发。后来我改成组合版节流，并在按钮回调里保留一个“最后点击”的补执行机制，问题就消失了。所以排查这类问题时，第一步不是改代码，而是先确认当前节流方案的边界行为是否匹配业务预期。
5.4 频繁创建和销毁防抖/节流函数要留意内存引用
还有一类隐蔽问题：在事件绑定里每次都新生成一个防抖函数，会导致旧的函数无法被正确解绑。
// 错误示例：每次都生成新函数，removeEventListener 永远移除不掉 window.addEventListener('scroll', debounce(handleScroll, 200)); window.removeEventListener('scroll', debounce(handleScroll, 200));正确做法是把防抖函数保存到变量中，绑定和解绑都使用同一个引用。在 React 函数组件里，如果要绑定事件，还需要把防抖函数实例放到 ref 或者 useEffect 内部创建，不能直接写在 render 方法里，否则每次渲染都会生成新的闭包和定时器状态。
5.5 压测与验证：怎么确认你的节流效果符合预期
最后分享一个小技巧。写完防抖或节流函数后，不要急着接业务，先写一段简单的计数器压测代码，确认触发次数确实被控制住了。
let count = 0; const logThrottled = throttle(() => { count++; console.log('执行了一次，当前 count 为', count); }, 500); const timer = setInterval(() => { logThrottled(); }, 50); // 每 50ms 触发一次 setTimeout(() => { clearInterval(timer); console.log('最终执行次数：', count); }, 3000);这段代码每 50ms 触发一次，持续 3 秒，理论上会触发 60 次。如果节流效果正常，500ms 间隔下 count 最终应该大约为 6 次。如果你实测得出的 count 明显高于理论值，说明实现里可能出现了定时器没有被清、多次叠加的问题，可以顺着这个方向排查。
我个人在实际项目里的体会是，防抖和节流看似是“两行代码”的小工具，但真正把它们的行为边界、边界参数、取消机制吃透的人并不多。面试时能把实现细节讲清楚是加分项，工作时能根据业务场景选对函数才是基本功。如果你所在项目暂时没有引入工具库，我建议自己维护一个带cancel、flush、leading和maxWait的 debounce 工具函数，后续所有节流需求都能基于它实现，既减少依赖，又能完全掌控边界行为。
