防抖节流实战：提升前端性能的关键技巧

项目初期的技术选型

去年做了一个后台管理系统的搜索模块，需求是用户输入关键词时实时展示匹配结果。一开始没多想，直接在 input 的 oninput 里加了个 fetch 请求，结果 QA 一测就炸了——快速打字时，几十个请求同时发出去，接口直接限流，页面卡成幻灯片。

当时第一反应就是得上防抖（debounce）。毕竟这种场景太典型了：用户疯狂输入，但其实只有最后一次输入才真正需要触发搜索。节流（throttle）我也考虑过，但节流更适合像滚动、窗口 resize 这种需要定期响应的场景，而搜索明显是“等用户停手再干活”更合理。

核心代码就这几行

防抖的实现其实挺简单的，网上抄一份基础版就行。我一开始用的是这个：

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

然后在组件里这么用：

const searchInput = document.getElementById('search');
const debouncedSearch = debounce(handleSearch, 300);

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

看起来没问题，对吧？上线前自测也挺顺滑。但万万没想到，坑在后面等着呢。

最大的坑：性能问题

上线后第二天，监控报警说接口 QPS 飙高。查日志发现，有些用户还是能触发大量请求。我一开始以为是 delay 时间设短了（300ms 确实有点激进），改成 500ms 后问题依旧。

折腾了半天，终于发现问题出在 组件重复挂载 上。这个搜索框是在一个可切换的 Tab 页里，每次切换 Tab，React 组件会重新 mount/unmount。而我的 debounce 函数是在组件内部定义的：

// 错误示范！
useEffect(() => {
  const debouncedSearch = debounce(handleSearch, 500);
  // ...绑定事件
  return () => {
    // 这里只清除了事件监听，但没清除定时器！
  };
}, []);

结果每次切换 Tab，旧的 debounce 实例里的 timer 根本没被清理，新的又创建一个。用户来回切几次 Tab，就有好几个 timer 在后台蹲着，等 delay 到了就各自发请求。难怪 QPS 爆了。

更隐蔽的是，即使用户已经离开搜索页，那些残留的 timer 还可能触发 handleSearch，而这时组件可能已经 unmount，导致 setState 报错（虽然 React 18 后这类报错不 crash 了，但 console 一堆红还是很烦）。

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

后来我重写了 debounce 的清理逻辑，关键点有三个：

• 必须把 timer 暴露出来，让外部能手动清除。不能只靠 clearTimeout，因为组件销毁时可能 timer 还没执行完。
• 在组件卸载时，不仅要移除事件监听，还要主动 cancel 掉 pending 的 debounce。
• 避免在 render 或 useEffect 里重复创建 debounce 函数，最好用 useRef 缓存实例。

改完后的代码长这样（以 React 为例）：

import { useRef, useEffect } from 'react';

function SearchBox() {
  const debounceRef = useRef(null);

  useEffect(() => {
    // 创建带 cancel 方法的 debounce
    const createDebounce = (func, delay) => {
      let timer;
      const debounced = (...args) => {
        clearTimeout(timer);
        timer = setTimeout(() => func(...args), delay);
      };
      debounced.cancel = () => {
        clearTimeout(timer);
        timer = null;
      };
      return debounced;
    };

    debounceRef.current = createDebounce(handleSearch, 500);

    const handleInput = (e) => {
      debounceRef.current(e.target.value);
    };

    const inputEl = document.getElementById('search');
    inputEl?.addEventListener('input', handleInput);

    return () => {
      inputEl?.removeEventListener('input', handleInput);
      // 关键：卸载时取消所有 pending 的 debounce
      debounceRef.current?.cancel();
    };
  }, []);

  const handleSearch = (query) => {
    if (!query.trim()) return;
    fetch(https://jztheme.com/api/search?q=${encodeURIComponent(query)})
      .then(res => res.json())
      .then(data => {
        // 更新结果
      });
  };

  return <input id="search" />;
}

这里我特意给 debounce 函数加了 cancel 方法，这样在 cleanup 时能彻底清理。亲测有效，QPS 回到正常水平。

另一个小问题：防抖太“狠”

防抖调好后，又有用户反馈：“我打完字都 1 秒了，怎么还没出结果？” 原来是 delay 设 500ms 对某些用户来说还是太长，尤其是移动端网络慢的时候，感觉更迟钝。

我试过动态调整 delay：网络快时用 300ms，慢时用 800ms。但实现起来很麻烦，还得测网速，最后放弃了。折中方案是加个 loading 状态——用户一输入就显示“搜索中…”，这样即使延迟 500ms，用户也知道系统在工作，心理上没那么焦虑。这个改动很小，但体验提升很明显。

不过说实话，这个 loading 方案也没完全解决“延迟感”问题。只是权衡之下，比调 delay 更简单可靠。如果真要优化，可能得上节流+防抖混合（比如首次输入立即搜，后续输入防抖），但项目时间紧，就没折腾了。

回顾与反思

这次防抖的坑，说白了还是对“副作用清理”不够重视。以前总以为 clearTimeout 就够了，忽略了组件生命周期和闭包变量的纠缠。现在写类似逻辑，第一反应就是：“这个 timer 能在组件销毁时干净地清理掉吗？”

另外，防抖/节流不是银弹。像搜索这种场景，防抖确实合适；但如果是无限滚动加载，节流（比如每 200ms 检查一次是否到底）反而更合理。选型时得结合具体交互，别一股脑套模板。

最后效果嘛，接口 QPS 降了 80%，用户也没再投诉卡顿。虽然那个“延迟感”问题没根治，但加了 loading 后基本没人提了。技术债嘛，能跑就行（狗头）。

以上是我踩坑后的总结，希望对你有帮助。如果你有更好的防抖清理方案，或者遇到过类似问题，欢迎评论区交流！