搜索防抖实现详解与实际项目中的性能优化实践

先看效果，再看代码

搜索框输几个字就疯狂调接口？用户还没打完“苹果手机”，你已经发了5次请求，后端日志炸了，自己还一脸懵——别急，这事儿我上周刚干过。不是后端扛不住，是我前端没防抖。

防抖（debounce）真不是什么高深概念，就是“等用户停下来再干活”。但实操起来，细节特别多。下面这段代码我直接贴进项目里跑了三天，零报错，亲测有效：

function debounce(fn, delay) {
  let timer = null;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => {
      fn.apply(this, args);
    }, delay);
  };
}

// 使用示例：绑定到搜索输入框
const searchInput = document.getElementById('search');
const searchHandler = debounce((value) => {
  if (!value.trim()) return;
  fetch(https://jztheme.com/api/search?q=${encodeURIComponent(value)})
    .then(res => res.json())
    .then(data => renderResults(data));
}, 300);

searchInput.addEventListener('input', (e) => {
  searchHandler(e.target.value);
});

这个场景最好用：实时搜索 + 联想词

我们有个电商后台的SKU搜索页，用户每敲一个字就要查一次联想词（比如输“红”就出“红色T恤”“红酒杯”“红米Note”）。一开始没加防抖，用户快速连打“红色T恤”，光是“红”“红色”“红色T”三个阶段就触发了3次请求，而且后发的请求返回得快，把前面的结果覆盖掉了——UI上反复闪动，体验极差。

改完之后，只在用户停顿300ms后才发最后一次请求。注意：这里用 input 事件，不是 change，也不是 keyup（后者对中文输入法不友好，用户还没选词就触发了）。

另外，我建议 delay 设为 300，别设成 100 或 500。100太激进，用户手指稍一停顿就发了；500又太迟钝，尤其移动端，用户觉得“怎么没反应”。300 是我从 Chrome DevTools 的 Performance 面板里反复测出来的平衡点——既不卡，也不滥发。

踩坑提醒：这三点一定注意

• 闭包里的 timer 变量必须独立作用域：如果你把 debounce 函数写成箭头函数或者直接内联在监听里，timer 会共享，多个输入框互相干扰。我第一次就犯了这个错，A框输入，B框的搜索结果也刷新了，折腾了半天才发现是 timer 没隔离。
• 取消请求比防抖更重要：防抖只是减少请求数，但万一用户输到一半切走了，或者点了别的按钮，上一个还没返回的请求还在跑。所以我在实际项目里加了 AbortController：

function debounceWithAbort(fn, delay) {
  let timer = null;
  let controller = null;
  return function (...args) {
    if (controller) controller.abort();
    clearTimeout(timer);
    controller = new AbortController();
    timer = setTimeout(() => {
      fn.apply(this, [...args, controller.signal]);
    }, delay);
  };
}

const searchHandler = debounceWithAbort((value, signal) => {
  fetch(https://jztheme.com/api/search?q=${encodeURIComponent(value)}, { signal })
    .then(res => res.json())
    .then(data => renderResults(data))
    .catch(err => {
      if (err.name !== 'AbortError') console.error('搜索失败', err);
    });
}, 300);

这个组合拳（防抖 + AbortController）才是真实生产环境该用的。别嫌麻烦，线上出了问题，你得半夜爬起来看监控。

• 不要在 Vue/React 组件里直接写 debounce：很多人喜欢在 setup() 或 useEffect 里定义 debounce 函数，结果组件重渲染时，函数被重新创建，timer 丢失，防抖失效。我的做法是：把 debounce 工具函数抽成独立文件（utils/debounce.js），或用 ref 存 timer：

// Vue 3 Composition API 示例
import { ref, onUnmounted } from 'vue';

export function useDebounce(fn, delay) {
  const timer = ref(null);
  const debouncedFn = (...args) => {
    if (timer.value) clearTimeout(timer.value);
    timer.value = setTimeout(() => {
      fn(...args);
    }, delay);
  };

  onUnmounted(() => {
    if (timer.value) clearTimeout(timer.value);
  });

  return debouncedFn;
}

高级技巧：带立即执行的防抖（immediate）

99% 的搜索场景用普通防抖就够了。但有一次做管理后台的“高级筛选”，用户点“重置”按钮后要立刻清空结果并重载默认数据，然后再等他输新条件。这时候就得用“立即执行版”防抖：第一次调用立刻执行，后续调用仍按 delay 防抖。

代码其实就改一行：

function debounceImmediate(fn, delay, immediate = false) {
  let timer = null;
  return function (...args) {
    const callNow = immediate && !timer;
    clearTimeout(timer);
    if (callNow) {
      fn.apply(this, args);
    }
    timer = setTimeout(() => {
      if (!immediate) {
        fn.apply(this, args);
      }
      timer = null;
    }, delay);
  };
}

用法一样，加个第三个参数就行：debounceImmediate(handler, 300, true)。不过说实话，我只用过两次，一次是上面说的重置场景，另一次是调试时想确认函数是否真的被调用了……真没必要为了炫技硬套。

最后说点实在的

防抖不是银弹。它解决的是“高频触发+低频响应”的问题，但如果用户就是慢吞吞一个字一个字打（比如老年人或用外接键盘），300ms 延迟反而显得卡。这时候你得配合 loading 状态、骨架屏、甚至本地缓存（比如搜过的词存在 localStorage 里，秒出历史结果）一起上。

还有，别忘了测试中文输入法！用拼音打“zhongguo”，在“zhong”、“zhongg”、“zhonggu”阶段都不该触发请求，只有最终“中国”上屏才算。Chrome 和 Safari 表现一致，但某些安卓 WebView 会有差异，建议在真机上跑一遍。

以上是我踩坑后的总结，希望对你有帮助。这个技巧的拓展用法还有很多，比如和节流混用控制滚动搜索、结合 Web Worker 做本地模糊匹配、甚至用 IntersectionObserver 替代部分搜索逻辑……后续会继续分享这类博客。

如果你有更好的实现方式，尤其是针对 React 18 并发渲染或 Vue 3 异步更新的优化方案，欢迎评论区交流。毕竟，谁还没被 input 事件坑过呢？