防抖本身不解决竞态问题，需配合AbortController主动中止旧请求；防抖延迟设为200～400ms最合理，300ms兼顾响应与体验；组件卸载时须清理请求以防内存泄漏；防抖仅为调度器，非请求拦截器。
防抖本身不解决竞态，它只控制函数“什么时候执行”，而不是“怎么取消已发出的请求”。当回调是 async/await 异步函数（比如调用 fetch 或 axios）时，若不做额外处理，旧请求仍可能在新请求之后返回，覆盖 UI 数据——这就是典型的竞态问题。
必须配合 AbortController 主动中止旧请求
每次新搜索触发前，要主动 abort 上一个未完成的请求：
- 用
useRef保存当前活跃的AbortController实例 - 在防抖回调执行前，先调用
controller.abort()（忽略 AbortError 报错） - 新建 controller，并把
signal传给fetch或 axios 的配置项 - 在
catch中过滤AbortError，避免干扰正常错误处理
防抖延迟设在 200～400ms 最合理
这个区间兼顾响应速度与防抖效果：
- 低于 200ms：用户打字稍快（如每秒 5 字），仍可能触发多次请求
- 高于 400ms：输入“react”后稍作停顿再按回车，建议框明显延迟，体验断裂
- 实测 300ms 能较好匹配主流输入法节奏，桌面端和安卓都较稳
组件卸载时务必清理请求
如果请求还没返回、组件却已卸载，继续更新状态会报 warning，甚至引发内存泄漏：
- 在
useEffect的 cleanup 函数中调用controller.abort() - 或在异步请求发起前加一层
if (!controller.signal.aborted)判断 - 确保
setState不会在卸载组件上调用（可用mountedRef辅助判断）
别把防抖误当成“请求拦截器”
防抖只是调度器，不是网络层代理：
- 它不会修改、劫持或重写你的 fetch 或 axios 调用逻辑
- 90% 的输入根本没走到发请求那一步，但一旦发出去，就得靠 AbortController 收尾
- 如果只用防抖不配取消机制，依然会出现“后输先显、先输后显、最终显示错词”的情况
