防抖的核心是“重置等待”而非“延迟”，通过闭包封装定时器timer实现每次触发清除前次计时、重设倒计时，确保只响应最终稳定输入，降低无效请求与后端压力。
防抖的核心不是“延迟”，而是“重置等待”。它靠闭包把定时器变量 timer 封装在函数内部，确保每次触发都能清除前一次计时、重新开始倒计时——这才是搜索联想不发多余请求的关键。
为什么搜索框必须用防抖？
用户输入是连续动作：打“北京”两个字，实际触发了“北”“北京”两次输入事件。若每次按键都发请求，后端会收到大量无效或过期的查询（比如“北”还没查完，“北京”请求又来了）。防抖让系统只响应最终稳定输入，大幅降低请求量和后端压力。
闭包怎么保存 timer 状态？
防抖函数返回一个新函数，这个函数能持续访问外层定义的 timer 变量，哪怕原函数已执行完毕。这种“变量不被回收”的机制，就是闭包——它让 timer 成为跨多次事件调用的共享状态，而不是每次调用都新建一个局部变量。
- 第一次输入“北”，timer 被设为 setTimeout，500ms 后准备发请求
- 0.3 秒后又输入“京”，clearTimeout(timer) 清掉上次计时，再设新 timer
- 用户停顿超过 500ms，新 timer 执行，真正发送“北京”的请求
实际代码里要注意什么？
闭包虽好，但 timer 必须声明在防抖函数内部，不能挂到全局或 DOM 元素上。否则多个输入框共用同一个 timer，会相互干扰。
- ✅ 正确：每个 debounce 调用都生成独立闭包，各自维护 timer
- ❌ 错误：用
fn.timer = setTimeout(...)，不同输入框会覆盖彼此的 timer - 额外建议：可加个立即执行标志（如 leading 选项），满足“首次输入立刻查、后续等停顿”这类混合需求
不只是搜索，这些地方也依赖同一机制
手机号校验、邮箱格式检查、按钮防重复提交，逻辑本质一致：用户操作高频但结果只需确认最终状态。闭包缓存 timer 的方式，让前端能冷静判断“什么时候才算真的结束了”，而不是被每一次微小变化牵着走。
