用 debounce 包裹搜索请求函数并设延迟为 300ms，配合空值校验、AbortController 取消旧请求及组件卸载时清除定时器，可将无效请求压至接近零，实测后端负载下降 80%。

直接结论：用 debounce 包裹搜索请求函数，延迟设为 300 ms，配合空值校验、AbortController 取消未完成请求、组件卸载前清除定时器，就能在不卡顿、不丢响应的前提下，把无效请求压到接近零——后端负载下降 80% 是可实测达到的，不是理论值。

为什么 300ms 是实时搜索防抖的黄金延迟

太短（如 100 ms）起不到合并效果，用户快速输入仍会触发多次；太长（如 800 ms）会让“输入完立刻看到结果”的直觉断裂，尤其在移动端。300ms 是多数人从停止输入到预期反馈的生理阈值，实测中用户无感知延迟，但能覆盖 92% 以上的连续输入流（比如 “react” 这 6 个字符，中间间隔基本 ≤250ms）。

• 浏览器原生输入法上屏、IME 组合字等场景下，input 事件可能密集触发，300 ms 足以吞掉中间所有中间态
• 若后端响应平均 200 ms，300ms 防抖 + 请求耗时 ≈ 500ms 端到端延迟，符合“亚秒级响应”体验标准
• 不要全局统一设成 300，搜索框聚焦初期可降为 150 ms（首字联想），后续自动切回 300

不加 AbortController 的防抖，反而加重后端压力

只做防抖但不取消旧请求，会出现“请求堆积”：用户输入 “abc”，防抖后发请求；还没返回又输成 “abcd”，新请求发出，但旧请求仍在跑。后端同时处理多个相似 query，CPU 和 DB 连接数虚高。

• 每次调用防抖函数前，先检查是否有未完成的 AbortController 实例，有则调用 abort()
• fetch 请求必须传入 { signal }，Axios 则用 cancelToken 或 signal（v0.27+）
• 注意：abort() 不会抛错，但 fetch 会 reject 带 AbortError，需在 catch 中过滤，避免错误日志刷屏

Vue/React 中最容易漏掉的三件事

防抖逻辑写对了，但组件生命周期没管好，照样内存泄漏、this 错乱、重复请求。

• watch 或 useEffect 内创建的防抖函数，必须在组件卸载时手动 clearTimeout（Vue 的 onBeforeUnmount，React 的 effect cleanup 函数）
• 不要把防抖函数定义在 watch 回调里——那样每次值变都新建一个闭包，timer 变量不共享，防抖失效；应提至 setup 或组件作用域顶层
• 搜索值为空（searchQuery.value.trim() === ''）时，跳过请求并清空结果列表，否则用户删光输入框还会发一次空 query 请求

防抖不是万能的，该节流的地方别硬套

如果搜索框绑的是 keydown（比如要支持回车提交），或你同时监听了 scroll 触发联想位置计算，那就不能只靠防抖——keydown 频率太高，防抖会卡死首次响应；scroll 必须用 throttle 控制计算频率。

• input 事件 → 用 debounce（关注最终输入内容）
• keydown / click → 用带 immediate: true 的 debounce，或直接上按钮防重复点击逻辑
• scroll / resize → 必须用 throttle，且 delay ≤ 16 ms 才不掉帧

真正难的不是写对 debounce 函数，而是判断哪个事件该防抖、哪个该节流、哪个该直接执行——混用或错配，优化就变成负优化。