在我们日常的开发中经常会用到一些容易被反复触发的事件。比如：scroll、resize、鼠标事件(mousemove,mouseover等)、键盘事件(keyup、keydown)。
频繁触发回调导致的大量计算会引发页面的抖动甚至卡顿。为了规避这种情况，我们需要一些手段来控制事件被触发的频率。就是在这样的背景下，throttle(事件节流)和 debounce(事件防抖)出现了。
“节流”与“防抖”的本质
这两个东西都以闭包的形式存在。
它们通过对事件对应的回调函数进行包裹、以自由变量的形式缓存时间信息，最后用 setTimeout 来控制事件的触发频率。
Debounce
防抖的概念其实是从机械开关和继电器的“去弹跳”(Debounce)衍生 出来的，基本思路就是把多个信号合并为一个信号。
手机拍照也有相似的概念，在拍照的时候手如果拿不稳晃的时候拍照，一般手机是拍不出好照片的，因此智能手机是在你按一下的时候连续拍许多张， 能过合成手段，生成一张，也就是我们平常说的HDR。翻译成JS就是，事件内的N个动作会被忽略，只有事件后由程序触发的动作才是有效的。
将目标方法(动作)包装在setTimeout里面，然后这个方法是一个事件的回调函数，如果这个回调一直连续执行，那么这些动作就一直不执行。为什么不执行呢，我们搞了一个clearTimeout，这样setTimeout里的方法就不会执行！ 为什么要clearTimeout呢，我们就需要将事件内的连续动作删掉嘛！待到用户不触发这事件了。那么setTimeout就自然会执行这个方法。那么这个方法用在什么地方呢，就是用于input输入框架的格式验证，假如只是验证都是字母也罢了，太简单了，不怎么耗性能，如果是验证是否身份证，这性能消耗大，你可以隔170ms才验证一次，或者更长的时间。这时就需要这个东西。或者你这个是自动校验，需要将已有的输入数据往后端拉一个列表，频繁的交互，后端肯定耗不起，这时也需要这个，如隔350ms。下面我们来实际写一个防抖：
// fn是我们需要包装的事件回调, delay是每次推迟执行的等待时间
function debounce(fn, delay) {
// 定时器
let timer = null
// 将debounce处理结果当作函数返回
return function () {
// 保留调用时的this上下文
let context = this
// 保留调用时传入的参数
let args = arguments
// 每次事件被触发时，都去清除之前的旧定时器，这里是闭包，timer变量必须清除
if(timer) {
clearTimeout(timer)
}
// 设立新定时器
timer = setTimeout(function () {
fn.apply(context, args)
}, delay)
}
}
// 用debounce来包装scroll的回调
const better_scroll = debounce(() => console.log('触发了滚动事件'), 1000)
document.addEventListener('scroll', better_scroll)
Throttle
节流的概念可以想象一下水坝，你建了水坝在河道中，不能让水流动不了，你只能让水流慢些。换言之，你不能让用户的方法都不执行。如果这样干，就是debounce了。为了让用户的方法在某个时间段内只执行一次，我们需要保存上次执行的时间点与定时器。下面来实际写一个节流:
// fn是我们需要包装的事件回调, interval是时间间隔的阈值 由于是闭包，last值可以保存上次的触发时间，不会重置为0if (now - last >= interval) {用 Throttle 来优化 Debounce
debounce 的问题在于它“太有耐心了”。试想，如果用户的操作十分频繁——他每次都不等 debounce 设置的 delay 时间结束就进行下一次操作，于是每次 debounce 都为该用户重新生成定时器，回调函数被延迟了不计其数次。频繁的延迟会导致用户迟迟得不到响应，用户同样会产生“这个页面卡死了”的观感。
为了避免弄巧成拙，我们需要借力 throttle 的思想，打造一个“有底线”的 debounce——等你可以，但我有我的原则：delay 时间内，我可以为你重新生成定时器；但只要delay的时间到了，我必须要给用户一个响应。这个 throttle 与 debounce “合体”思路，已经被很多成熟的前端库应用到了它们的加强版 throttle 函数的实现中：
// fn是我们需要包装的事件回调, delay是时间间隔的阈值
timer = setTimeout(如果觉得本文对你有所帮助，不如点个在看再走。
)
