防抖函数通过“延迟执行+重置计时”机制将连续多次触发压缩为一次执行，只响应最后一次操作：首次触发启动定时器，后续触发在延迟期内清除旧定时器并重启，延迟结束后执行函数；需正确清除定时器并保持this和参数上下文；适用于搜索框输入、resize、表单验证等需等待用户操作结束的场景。
防抖函数通过“延迟执行 + 重置计时”机制，把连续多次触发压缩成一次执行，从而显著减少高频事件下的函数调用次数。
核心逻辑：只响应最后一次操作
用户在短时间内反复触发事件（比如快速输入、滚动、缩放窗口），防抖不会每次响应，而是等待用户“停下来”——即最后一次触发后，经过设定的延迟时间（如300ms）再执行函数。中间所有触发都被忽略。
- 第一次触发 → 启动一个300ms定时器
- 第2、3、4次触发（都在300ms内）→ 清除前一个定时器，重新启动新的300ms定时器
- 300ms内没再触发 → 定时器到期，真正执行函数
关键实现细节：定时器管理与上下文保持
一个可靠的防抖函数必须正确处理两件事：清除旧定时器、保留this和参数。
- 用
clearTimeout及时清理上一次未执行的定时器，避免误执行 - 保存当前调用的
this和arguments（或用...args），确保函数内部能访问正确的上下文和传入值 - 推荐使用
func.apply(context, args)或func.call(context, ...args)来调用原函数
典型应用场景与效果对比
不加防抖时，输入框每敲一个键就发一次请求，10次输入可能触发10次接口；加上300ms防抖后，用户停顿半秒才发一次请求，实际只调用1次。
- 搜索框输入：用户打字“react”，5个字符触发5次，防抖后只在最后停顿时查一次“react”
- resize事件：浏览器拖拽窗口大小时每毫秒都触发，防抖可将几十次回调压成1次布局计算
- 表单验证：用户还在修改手机号，不急着校验；等他停下手，再检查格式是否合法
常见误区提醒
防抖不是“限制频率”，而是“等待静默”。它适合需要“用户操作结束才响应”的场景。
- 别把它用在需要实时反馈的地方（如打字时显示字数，这时该用节流或直接执行）
- 延迟时间不宜过短（500ms）——影响交互感知
- 注意内存泄漏风险：如果防抖函数绑定在长期存在的DOM元素上，需确保组件卸载时清除相关定时器（如React中useEffect cleanup）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
