防抖函数需用闭包保存 timerId 并返回稳定引用，否则无法清除前次定时器；lodash 的 maxWait 防止请求永久不触发；应快照输入值传参而非事件中读取；还需配合 AbortController 取消旧请求及 loading 状态。
防抖函数为什么不能直接套用 setTimeout 就完事
很多人写防抖第一反应是每次输入都 setTimeout，然后用 clearTimeout 清上一次——这逻辑没错，但漏掉了关键点：setTimeout 返回的 timer ID 是局部变量，如果没把它存到闭包或外部可访问的位置，下一次调用就清不掉前一个定时器。
真正能复用的防抖函数必须返回一个“稳定引用”的函数，且内部维护一个共享的 timerId。否则每次输入都会堆积未执行的请求。
实操建议：
- 用闭包保存
timerId，不要在事件回调里声明它 - 确保防抖后的函数是同一个引用（比如赋给
input事件时不要每次重生成） - 考虑首次触发是否立即执行（通常搜索场景不需要，设为
leading: false）
lodash.debounce 的 maxWait 参数在搜索框里有什么用
默认的 lodash.debounce(func, wait) 只保证“最后一次触发后 wait 毫秒才执行”，但如果用户狂敲不止，函数可能永远不执行——比如每 200ms 输入一次，wait=500，那定时器永远被清除重设。
maxWait 就是兜底机制：不管中间清了多少次，最多等 maxWait 毫秒就必须执行一次。对搜索框很实用，避免用户输了一长串却迟迟没响应。
示例：
const search = debounce(fetchSuggestions, 500, { maxWait: 1000 });
这意味着：用户持续输入时，最迟 1000ms 内一定会发一次请求，哪怕中间清了 4 次定时器。
输入框绑定防抖函数时，如何安全获取当前值
防抖函数延迟执行，但执行时 event.target.value 可能已变（比如用户又输了几个字），也可能 DOM 节点已被移除（如切换 Tab 或组件卸载）。直接读 event.target.value 不可靠。
正确做法是：在事件触发瞬间把需要的值“快照”下来，传给防抖函数。
实操建议：
- 不要在防抖函数体内读
event.target，而是在input事件回调里取值并作为参数传入 - 如果用 React，注意函数组件中闭包可能捕获旧 state，应配合
useRef存最新值或用useCallback依赖更新 - 原生 JS 示例：
input.addEventListener('input', () => { const query = input.value.trim(); if (query) debouncedSearch(query); });
防抖后还要处理请求取消和 loading 状态吗
要。防抖只控制“发多少次”，不解决“发出去的请求要不要取消”或“UI 怎么反馈”。比如用户输 “react”，防抖后发了请求；刚发完又输成 “react native”，新请求发出前，老请求还在 pending——它仍可能回来覆盖结果，造成 UI 错乱。
所以必须配套做两件事：
- 用
AbortController在新请求发起时 abort 上一个（现代浏览器支持良好） - 加 loading 状态防重复点击或展示等待态，尤其当防抖延迟较长（如 800ms）时，用户需要感知系统在忙
- 注意：
AbortController实例不能复用，每次请求都要新建
防抖 + 取消 + loading 是搜索框请求控制的最小可靠组合，少一个都容易出问题。
