防抖是在事件停止触发后延迟执行，适用于搜索框输入等关注最终结果的场景；节流则在固定时间间隔内只执行一次，适用于滚动加载等需持续反馈的场景。
JavaScript中的防抖（Debounce）和节流（Throttle）是两种优化高频事件处理的常用技术，它们的核心目标都是限制函数执行的频率，以提升页面性能和用户体验。简单来说，防抖是在事件触发后，等待一段固定的时间，如果在等待时间内事件再次触发，则重新计时，直到事件停止触发一段时间后才执行函数；而节流则是在一段时间内，无论事件触发多少次，都只执行一次函数。
解决方案
要实现JavaScript中的防抖与节流，我们可以利用闭包和定时器（
setTimeout
）。这两种模式在前端开发中非常常见，比如处理窗口resize、输入框搜索、按钮点击等场景。
防抖的实现：
防抖的关键在于“延迟执行”和“重新计时”。每次事件触发时，我们都清除之前的定时器，并设置一个新的定时器。
立即学习“Java免费学习笔记（深入）”；
function debounce(func, delay) { let timeoutId; // 用于存储定时器ID return function(...args) { const context = this; // 保存函数执行时的上下文 clearTimeout(timeoutId); // 每次事件触发都清除之前的定时器 timeoutId = setTimeout(() => { func.apply(context, args); // 延迟执行函数 }, delay); }; } // 示例用法： // const myEfficientFn = debounce(() => console.log('频繁操作，但我只执行一次'), 500); // window.addEventListener('resize', myEfficientFn); // document.getElementById('search-input').addEventListener('input', myEfficientFn);
这段代码里，
debounce
函数返回了一个新的函数。当这个新函数被调用时，它会先清除掉之前可能存在的定时器，然后重新设置一个定时器。这意味着，只有当事件停止触发
delay
毫秒后，
func
才会被真正执行。如果在这
delay
毫秒内事件又触发了，那么之前的定时器就被“取消”了，重新开始计时。
节流的实现：
节流的关键在于“控制频率”。它确保在设定的时间间隔内，函数最多只执行一次。
function throttle(func, limit) { let inThrottle; // 标志位，表示是否在节流期内 let lastFunc; // 存储最后一次要执行的函数 let lastRan; // 存储上一次函数执行的时间 return function(...args) { const context = this; // 保存函数执行时的上下文 if (!inThrottle) { func.apply(context, args); // 立即执行一次 lastRan = Date.now(); inThrottle = true; } else { clearTimeout(lastFunc); // 如果在节流期内，清除之前的延迟执行 lastFunc = setTimeout(() => { if ((Date.now() - lastRan) >= limit) { func.apply(context, args); // 延迟执行，确保在节流期结束后执行 lastRan = Date.now(); } }, limit - (Date.now() - lastRan)); // 计算剩余时间进行延迟 } }; } // 示例用法： // const myEfficientScroll = throttle(() => console.log('滚动事件，每秒最多执行一次'), 1000); // window.addEventListener('scroll', myEfficientScroll);
这里的
throttle
实现稍微复杂一些，它结合了立即执行和延迟执行的策略。当事件第一次触发时，函数会立即执行。然后进入一个“冷却期”（
inThrottle
为
true
）。在这个冷却期内，后续的事件触发不会立即执行函数，而是会设置一个定时器，等待冷却期结束后执行。这种实现方式可以确保在设定的
limit
时间内，函数不会被频繁调用，同时也能响应到用户在冷却期内的最后一次操作。当然，节流还有另一种常见的实现方式，只通过定时器来控制，即第一次触发不立即执行，而是等待
limit
时间后执行。上述示例是“立即执行一次，后续等待”的策略。
防抖与节流的应用场景有哪些？
这两种优化技术在前端开发中简直是“万金油”，用得好能显著提升用户体验和页面性能。
比如，防抖最典型的应用场景就是搜索框的实时搜索建议。用户在输入框里敲字时，你肯定不希望每敲一个字母就立即发送一次网络请求去获取建议。那样不仅会给服务器造成巨大压力，用户体验也糟透了。使用防抖，只有当用户停止输入一段时间（比如300ms或500ms）后，才发送请求。这样既减少了不必要的请求，又能及时给出搜索建议。
再比如，窗口大小调整（
window.resize
）事件。用户拖拽浏览器窗口时，这个事件会以极高的频率触发。如果你的页面里有复杂的布局计算或图表重绘逻辑，每次
resize
都执行一遍，那页面分分钟卡死。用防抖处理，只在用户停止调整窗口大小后，才进行一次最终的布局计算或重绘。
至于节流，它最常用于滚动事件（
window.scroll
）。当你需要根据滚动位置加载更多内容（无限滚动）、显示/隐藏导航栏、或者做一些滚动动画时，
scroll
事件的频繁触发同样是个大问题。用节流来限制它的执行频率，比如每200ms或500ms执行一次，就能平滑地处理这些逻辑，避免卡顿。
另一个常见场景是按钮的重复点击。有些用户手速快，或者网络延迟高，可能会在短时间内多次点击同一个提交按钮。如果不加处理，可能会导致重复提交表单或多次触发相同的操作。使用节流，可以确保在一定时间内，按钮点击事件只被处理一次，防止误操作。
还有，鼠标移动（
mousemove
）事件，比如拖拽功能或者需要根据鼠标位置进行实时反馈的场景。如果
mousemove
事件的处理逻辑比较复杂，节流就能派上用场，限制更新频率，保持动画流畅。
总的来说，防抖适用于那些“只关心最终结果”的场景，比如搜索、
resize
；而节流则适用于那些“需要持续响应，但不能太频繁”的场景，比如滚动、拖拽、频繁点击。
防抖与节流的实现原理有何不同？
虽然防抖和节流都是为了优化高频事件，但它们的内在逻辑和对事件的处理方式有着本质的区别。理解这些差异有助于我们更好地选择何时使用哪种技术。
防抖（Debounce）的原理是“延迟执行，取消重置”。 它的核心思想是：在一个事件被触发后，并不立即执行对应的处理函数，而是设定一个定时器。如果在定时器设定的延迟时间内，该事件再次被触发，那么之前的定时器就会被“取消”，并重新设定一个新的定时器。这意味着，只有当事件停止触发，并且经过了设定的延迟时间后，处理函数才会被真正执行。如果事件持续不断地触发，那么处理函数将永远不会执行，直到事件流中断。
你可以把它想象成一个“稍等片刻”的机制。比如，你打电话给客服，客服说“请稍等”，如果你在等待期间又说了话，客服会重新说“请稍等”，直到你彻底安静下来，客服才会回答你的问题。
节流（Throttle）的原理是“控制频率，周期执行”。 它的核心思想是：在一个事件被触发后，处理函数会立即执行（或者在设定的时间间隔开始时执行）。然后，在设定的时间间隔内，无论该事件被触发多少次，处理函数都不会再次执行。只有当这个时间间隔结束后，处理函数才能再次被执行。它就像给函数执行加了一个“冷却时间”。
你可以把它想象成一个“限流闸口”。比如，一个水龙头每秒最多只能流出1升水。无论你把水龙头开多大，每秒流出的水都不会超过1升。在设定的时间周期内，只有第一次触发有效，后续触发会被忽略，直到周期结束。
核心差异总结：
- 触发条件： 防抖是“事件停止触发后执行”，节流是“在一段时间内只执行一次”。
- 执行次数： 防抖在持续触发的情况下，可能只执行一次（事件停止后）；节流在持续触发的情况下，会按照设定的时间间隔周期性地执行。
- 关注点： 防抖更关注“最后一次操作的结果”，节流更关注“操作的频率和持续性”。
理解了这些原理上的差异，在面对具体业务场景时，你就能更清晰地判断应该使用防抖还是节流来优化你的代码了。
如何选择合适的防抖或节流策略？
选择防抖还是节流，并不是一个非此即彼的简单问题，它更多地取决于你希望事件处理函数在用户交互过程中扮演的角色，以及你对性能和用户体验的权衡。这就像你在厨房里，根据菜品选择用煎锅还是炒锅，各有各的用处。
首先，问自己一个问题：“我更关心用户操作的‘最终结果’，还是‘过程中的持续反馈’？”
如果你更关心最终结果，那么防抖通常是更好的选择。
- 场景： 搜索框输入、
window.resize
事件、表单验证（用户输入完成后才进行验证）。
- 理由： 在这些场景下，我们通常只需要在用户停止操作后，对最终的状态进行一次处理。频繁的中间状态处理不仅浪费资源，也可能导致不必要的UI抖动或网络请求。例如，用户在搜索框里输入“JavaScript”，我们只需要在他输入完毕后，用完整的“JavaScript”去搜索，而不是在他输入“J”、“Ja”、“Jav”时都去搜索。
如果你需要持续的反馈，但又不想让函数执行得过于频繁，那么节流往往更合适。
- 场景： 页面滚动加载（无限滚动）、鼠标移动拖拽、按钮点击防止重复提交、游戏中的技能冷却。
- 理由： 在这些场景下，用户希望能够持续地得到反馈，但过高的执行频率又会造成性能问题。节流可以在保证一定响应性的前提下，限制函数的执行频率。例如，页面滚动时，我们需要周期性地检查是否需要加载更多内容，但不需要每次滚动一个像素就检查一次。
除了核心需求，还可以考虑以下几点：
-
用户体验：
- 防抖： 可能会带来轻微的“延迟感”，因为用户操作后需要等待一段时间才能看到结果。但对于某些操作（如搜索），这种延迟是可接受的，甚至能让用户觉得系统更“聪明”，因为它知道用户还没输完。
- 节流： 通常能提供更实时的反馈，因为函数会周期性地执行。这对于需要平滑动画或持续更新的场景非常重要。
-
性能开销：
- 两者都能有效降低函数执行频率，从而提升性能。但具体选择哪一个，还要看你的处理函数本身的计算复杂度以及事件触发的频率。
- 如果处理函数非常耗时，且事件触发非常密集（比如
mousemove
），节流可能更直接地限制了总的执行次数。
-
实现复杂度：
- 通常情况下，防抖的实现逻辑相对简单直观，因为它只关心最后一次事件。
- 节流的实现可能会稍微复杂一些，因为它需要管理时间间隔，有时还需要考虑是立即执行还是延迟执行等策略。
没有绝对的最佳实践，只有最适合你当前业务场景的方案。在实际开发中，你甚至可能会遇到需要结合使用防抖和节流的复杂场景，或者根据不同设备的性能差异，动态调整防抖或节流的延迟/间隔时间。多思考，多尝试，才能找到最优雅的解决方案。
javascript java 前端 浏览器 app 前端开发 win 区别 点击事件 重绘 JavaScript 表单验证 闭包 事件 ui