防抖把请求压到300ms，用户却被7年前的结果糊脸

300毫秒的防抖延迟，能拦住90%的无效请求，却拦不住一个更隐蔽的bug：当用户把"apple"改成"apples"，前一个请求的响应可能后脚追上，把过时的结果拍在最新的搜索框里。这不是假设，是生产环境里反复出现的 race condition（竞态条件）。

前端工程师对防抖太熟悉了。输入框监听 onChange，lodash.debounce 一裹，300ms 没人打字再发请求——服务器压力小了，浏览器也轻快。但很多人没意识到，防抖只管"发"，不管"收"。它像是一个尽职的门卫，确认访客没急事才放行，却从不问里面是不是已经挤满了人。

当两个请求在网线里赛跑

原文作者举了一个典型场景：用户输入"apple"，300ms 后请求 A 出发；用户立刻删改，输入"apples"，请求 B 紧随其后。由于网络抖动，A 走了条远路，B 抄了近道。结果？B 先回来，UI 更新为"apples"的结果；半秒后 A 姗姗来迟，把"apple"的列表盖了上去。

用户盯着屏幕懵了：我刚打的字是"apples"，怎么出来一堆苹果手机？

这个问题在慢网环境（3G、地铁信号、跨洋服务器）下被无限放大。防抖的延迟阈值设得越短，请求并发概率越高；设得越长，用户体感越卡。这是一个没有赢面的平衡游戏。

齿轮系统缺了一个刹车片

原文用了一个精妙的机械类比：用户输入是扳动杠杆，网络请求是一组齿轮。防抖相当于在杠杆和齿轮之间加了一个阻尼器，防止扳得太快把机器搞坏。但如果齿轮已经在转，新的扳动不会让它停下来——旧齿轮继续 grinding（研磨），新齿轮又启动，两者撞在一起。

摩擦产生热量，热量导致故障。对应到代码里，就是内存泄漏（未清理的 Promise）、状态错乱（setState 时组件已卸载）、以及用户看到的数据与输入框内容彻底脱节。

更麻烦的是重试逻辑。很多开发者给请求加了自动重试，遇到 5xx 或超时便立即再来一次。没有退避策略（backoff）的重试，配合防抖的"节流"假象，会把服务器当成打地鼠的靶子——用户那边只敲了一次键盘，服务端已经收到十几波攻击。

AbortController：给请求装一个急停按钮

现代浏览器提供的 AbortController（中止控制器）是这个齿轮系统缺失的刹车片。它的用法很直白：每次发起新请求前，先 abort 掉上一次的 signal（信号）。Fetch API 和 Axios 都支持这个机制。

代码层面的改动不大，但思维模型要换。以前防抖的逻辑是"等用户消停了再发"，现在要变成"用户一动，旧的立刻死"。这不是优化，是正确性。没有 cancellation 的防抖，在严格意义上只是一个性能补丁，而非可靠的 UX 保障。

原文还提到了两个常被忽略的配套措施：一是错误处理要区分"用户取消"和"真正失败"，前者静默吞掉，后者才弹提示；二是重试必须带指数退避，2秒、4秒、8秒地等，而不是无脑连点。

这三件套——防抖节流、请求取消、退避重试——单独看都是老生常谈，但组合起来才能覆盖完整的请求生命周期。很多团队只做了第一层，便在测试环境里觉得"挺流畅"，直到真实用户的慢网环境把问题炸出来。

为什么这个bug能藏七年

一个反直觉的事实：这个 race condition 在 React 生态里存在了至少七年。从 class 组件的 componentWillUnmount 里手动清定时器，到函数组件用 useEffect 的 cleanup 函数，再到现在的 useSWR、TanStack Query 等库内置的竞态处理——社区走了很长的弯路。

很多现代数据获取库已经内建了这些机制。SWR 的 dedupingInterval 和 keepPreviousData、React Query 的 cancelQueries，本质上都是在库层面补全防抖缺失的生命周期管理。但理解底层原理仍然重要，因为封装总有漏网之鱼：自定义 hook、原生 fetch 封装、或者某个"轻量"的第三方库。

原文最后抛了一个开放场景：想象工厂传送带上的工人随机抽走产品（模拟网络丢包），系统该如何保证最终到达包装环节的是正确批次？这个问题没有标准答案，取决于你的业务能容忍多大的延迟、多高的服务器成本、以及多乱的界面状态。

你的团队现在是怎么处理输入防抖的？有没有在生产环境踩过"旧响应覆盖新状态"的坑？