每次新输入前先 abort 上次请求并清除旧定时器，再新建 AbortController 实例传入 fetch；React 中用 ref 保存最新 controller 和 timer ID，在 useEffect 清理函数中 abort，并在 catch 中静默处理 AbortError。
AbortController 怎么配合防抖中断正在执行的 fetch 请求
直接结论：每次新输入触发搜索前，先调用上一次 abortController.abort()，再新建一个 AbortController 实例传给 fetch() 的 signal 选项。不这么做，旧请求不会自动取消，即使用户已经打了新关键词。
关键点在于：AbortController 只能 abort 一次，且 abort 后不能再复用；必须为每次 fetch 创建新实例。常见错误是把同一个 abortController 实例反复传给多个 fetch，结果只有第一次 abort 生效，后续请求完全不受控。
- 防抖函数内部需保存对上一个
abortController的引用（例如用闭包变量或 React ref） - 在 debounce timeout 触发前，若收到新输入，立刻调用旧
abortController.abort() - 然后新建
const abortController = new AbortController()，并把abortController.signal传入fetch(url, { signal }) - 注意：
fetch抛出的 abort 错误类型是DOMException，且name === 'AbortError'，不是网络错误，不应重试或弹 toast
React 里怎么安全地在组件卸载时清理 pending 请求
组件 unmount 时，如果还有未完成的搜索请求在 pending，不清理会导致 setState on unmounted component 警告，甚至内存泄漏。AbortController 本身不感知组件生命周期，得手动 hook 进去。
React 中推荐用 useEffect 清理函数 + ref 存储最新 abortController：
useEffect(() => {
return () => {
abortControllerRef.current?.abort();
};
}, []);注意不能在清理函数里直接调用 abortController.abort() —— 因为 ref 可能已被覆盖。必须用 ref 保持对“当前最新控制器”的引用，且确保清理时 abort 的是真正 pending 的那个。
- 不要在事件处理函数里直接 new AbortController 并存到 state，state 更新异步，ref 才能保证同步可读
- 如果用了自定义 hook 封装防抖搜索，该 hook 必须返回 ref 或提供 cleanup 方法
- 服务端响应极快时（比如本地 mock），可能刚发请求就 unmount，此时 abort 仍有效，但 Promise 会以 reject 结束，需在 catch 里判断
error.name === 'AbortError'后静默忽略
防抖 delay 和 abort 的时机冲突怎么避免
典型问题：用户快速连打 “abc”，debounce 设为 300ms，但第 2 次输入 “ab” 后立即 abort 了 “a” 的请求，300ms 后却触发了 “ab” 的搜索 —— 此时 “ab” 的 controller 其实已在第 3 次输入 “abc” 时被 abort，导致请求失败。
根本原因：debounce 的定时器和 abort 操作没对齐。正确做法是——每次新输入，不仅 abort 上次 controller，还要清除上一个 debounce timeout。
- 用
clearTimeout清掉旧 timer，再setTimeout新的，否则会出现“旧 timer 迟到执行”的竞态 - abort 和 clearTimeout 必须成对出现，缺一不可；漏掉 clearTimeout 就会触发已废弃的搜索
- timer ID 和 abortController 必须一一对应，建议用同一个 ref 对象同时存两者，比如：
{ controller: ac, timeoutId: tid } - 别依赖防抖库（如 lodash.debounce）的 cancel() 方法来代替 clearTimeout —— 它不保证 abort 行为同步发生，容易漏掉 signal 绑定
fetch abort 后 UI 状态怎么不乱
最常踩的坑：abort 后没重置 loading 状态，或者把 abort 当作失败处理，显示“请求失败”，造成体验断层。用户只是改了输入，不是网络坏了。
核心原则：abort 是预期中的流程控制，不是 error。UI 应只响应成功响应或真实网络异常。
- 在
fetch().then()里设 loading = false，success = true - 在
catch里只处理非 abort 错误：if (error.name !== 'AbortError') { /* 显示错误 */ }，其余情况什么也不做 - loading 状态应在 debounce 开始时置为 true，在 fetch resolve/reject（非 abort）后才置为 false；abort 不影响 loading，因为新请求马上要来
- 如果支持“搜索中…”文字提示，建议加个微延迟（比如 200ms）再显示，避免快速输入时 loading 闪现
AbortController 本身很简单，难的是把它严丝合缝嵌进防抖、组件生命周期、UI 状态这三者的时序里。最容易被忽略的，是 clearTimeout 和 abortController.abort() 必须严格配对，且发生在同一上下文；少一步，就会有请求幽灵般执行，或者 loading 卡死。
