在搜索联想场景下，用 debounce 能将连续输入 10 次触发的 10 次 API 请求压缩为 1 次，前提是用户停顿时间 ≥ 设定的 wait 值（如 300ms）；需配合 AbortController 解决竞态问题，并选用 input 事件、合理设置 wait（200～400ms）、动态获取 value。
直接上结论：在搜索联想场景下，用 debounce 能把连续输入 10 次触发的 10 次 API 请求，压到 1 次——前提是用户停顿时间 ≥ 你设的 wait 值（比如 300ms）。
为什么 input 事件不加防抖就容易炸接口
用户每按一个键（哪怕只是删掉一个字），input 事件就触发一次。如果直接在里面写 fetch(`/api/search?q=${value}`)，会出现这些典型问题：
- 用户打 “react” 5 个字，没等输完就删了重打，中间可能已发 4～5 次请求，后端全得接住、解析、查库、返回空结果
- 网络慢时，后发的请求反而先返回，导致 UI 显示“旧关键词”的结果（竞态问题）
- 前端没做取消逻辑的话，
fetch还在 pending，用户已切走，资源白占
debounce 的核心参数怎么选才不卡也不迟
关键就两个参数：func 和 wait。但实际用起来，有三个隐藏条件必须对齐：
-
wait值不是越小越好：设成 50ms，用户手速快一点还是连发；设成 800ms，用户会觉得“输完了还得等一下才出建议”，体验断层。实测 200～400ms 是多数场景的甜点区间 - 必须用
input事件，别用keyup：前者捕获所有输入（包括粘贴、语音、IME 上屏），后者漏掉很多场景 - 防抖函数要能拿到当前
input.value，不能闭包锁死初始值——所以通常要把获取值的逻辑放进防抖包裹的函数里，而不是传死参
手写 debounce 时最容易漏掉的竞态处理
基础版 debounce 只管“清上一个定时器”，但没管“上一个 fetch 还在跑”。结果就是：用户快速输入 “abc” → “ab” → “a”，最后只执行 fetch('/api/search?q=a')，但前两个请求还在 pending，可能后来返回并覆盖 UI。
正确做法是加一层 AbortController：
function debounce(func, wait) {
let timeoutId = null;
let controller = null;
return function (...args) {
if (controller) controller.abort();
controller = new AbortController();
clearTimeout(timeoutId);
timeoutId = setTimeout(() => {
func(...args, { signal: controller.signal });
}, wait);
};
}
// 使用时
const debouncedSearch = debounce((query, options) => {
fetch(`/api/search?q=${encodeURIComponent(query)}`, options)
.then(r => r.json())
.then(data => renderSuggestions(data));
}, 300);
注意：options 必须透传 signal，否则 abort 不生效。
用 Lodash 的 debounce 时要注意的兼容坑
如果你用 lodash.debounce，别直接传箭头函数进去——它会丢失 this，而某些封装的 fetch 工具依赖上下文绑定：
- ❌ 错误写法：
debounce(() => api.search(input.value), 300) - ✅ 正确写法：
debounce((value) => api.search(value), 300)，然后调用时传input.value - 另外，Lodash 版默认不支持
immediate: true（立即执行第一次），搜索联想不需要这个，但如果你误开，会导致“一输就查”，完全失去防抖意义
真正难的不是写防抖，而是判断什么时候该清掉上一个请求、什么时候该保留 loading 状态、以及如何让 UI 在“无响应感”和“过度延迟”之间不偏不倚——这些细节藏在每次 input 的毫秒级节奏里，而不是函数签名里。
