防抖和节流是事件处理的函数控制策略，非语法特性；防抖“等停手再执行”，适用于搜索、校验等场景；节流“固定频率执行”，适用于滚动、绘图等场景；二者需根据是否丢弃中间态、是否响应首尾等决策点合理选用。
防抖（debounce）和节流（throttle）不是语法特性，而是事件处理的函数控制策略——它们不改变 JavaScript 本身，但能显著减少高频触发时的执行次数，避免卡顿、重复请求或渲染压力。
防抖：debounce 怎么写？什么时候该用？
防抖的核心逻辑是「等用户停手再执行」。比如搜索框输入、窗口 resize 监听，你并不需要每次按键或每次缩放都立刻响应，而是等用户停下来（比如 300ms 内没再触发），才执行一次回调。
常见错误是把定时器定义在闭包外、或没清理上一次的 setTimeout，导致多次触发后只执行最后一次——但实际可能执行了中间某次，甚至漏掉最后一次。
正确做法是每次触发前先清除旧定时器：
立即学习“Java免费学习笔记（深入）”；
function debounce(fn, delay) {
let timer;
return function(...args) {
clearTimeout(timer);
timer = setTimeout(() => fn.apply(this, args), delay);
};
}- 适用于：输入搜索、表单校验、按钮防重复点击（配合
disabled更稳妥） -
delay太小（如 50ms）几乎无效；太大（如 1s）会明显感知延迟，通常 150–300ms 是较平衡的选择 - 注意：防抖函数返回的是新函数，需赋值给事件处理器，不能直接调用
节流：throttle 的两种主流实现方式
节流强调「固定频率执行」，比如滚动监听、鼠标移动轨迹采集，你希望每 100ms 最多执行一次，而不是等用户停下——否则用户快速滚动时根本收不到回调。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
常见误区是以为「用 setTimeout + 时间戳判断」就够了，但容易漏掉最后一次触发（比如用户拖到页面底部后停止，却没触发最终处理）。更稳妥的是双模式：时间戳 + 定时器兜底。
推荐使用时间戳 + 定时器组合的实现：
function throttle(fn, limit) {
let lastCall = 0;
let timer;
return function(...args) {
const now = Date.now();
if (now - lastCall >= limit) {
fn.apply(this, args);
lastCall = now;
} else if (!timer) {
timer = setTimeout(() => {
fn.apply(this, args);
lastCall = Date.now();
timer = null;
}, limit - (now - lastCall));
}
};
}- 适用场景：滚动加载、Canvas 绘图更新、游戏帧同步逻辑
- 纯时间戳版简单但可能丢失结尾；纯定时器版易堆积未执行任务；组合版兼顾及时性与完整性
- 注意：节流函数内部维护状态，不能直接用于多个不同上下文（如多个元素绑定同一节流函数但期望各自独立计时），需单独实例化
lodash.debounce 和 lodash.throttle 的默认行为差异
很多人直接引入 Lodash，但没注意它俩默认参数不同：debounce 默认启用 leading: false, trailing: true（首次不执行，末次执行）；而 throttle 默认是 leading: true, trailing: false（首次立即执行，末次不保证）。
这意味着：
- 如果你依赖「第一次触发就响应」（如点击按钮立刻禁用），要用
{ leading: true } - 如果必须确保最后一次触发被处理（如 resize 后要重排布局），对
debounce不用改，默认已支持；对throttle则需显式加{ trailing: true } - Lodash 的节流还支持
maxWait参数，防止因用户持续操作导致回调永远不执行——这是手写版常忽略的关键兜底机制
真正难的不是写出一个能跑的 debounce 或 throttle，而是想清楚：这个事件是否允许丢弃中间态？是否必须响应起始或结束？有没有并发上下文？这些决策点比代码本身更容易出错。
