应在发起 fetch 前检查 signal.aborted，因其是同步可读布尔值，能彻底避免已中止请求的网络开销；适用于防抖、组件卸载、条件变更等场景，需在函数入口、防抖回调或 useEffect 开头检查，并配合 catch 处理 AbortError。
直接检查 signal.aborted 是防止无效请求发出的轻量级前置拦截手段，比等 fetch 抛出 AbortError 更早、更干净。它不触发网络连接，也不占用资源，适合在防抖、快速切换、条件变更等场景中主动跳过已失效的请求。
为什么要在发起前检查 aborted？
fetch 内部虽会响应 signal 中止，但一旦调用 fetch，浏览器就可能已建立连接、发送请求头甚至部分 body。而 signal.aborted 是同步可读的布尔值，只要 controller 已 abort，该值立即为 true——此时完全跳过 fetch 调用，能彻底避免无谓开销。
- 防止防抖中旧请求在新请求触发后仍执行
- 避免组件卸载后因异步延迟仍调用 fetch
- 减少不必要的 TCP 握手与 DNS 查询
典型使用位置
检查应放在真正调用 fetch() 之前，且需确保 signal 引用未被覆盖或丢失：
- 在函数入口处：适合封装统一请求函数时做守卫
- 在防抖/节流回调内部：用户连续输入时，每次新请求前先判旧 signal 是否已中止
- 在 useEffect 的请求逻辑开头：配合 cleanup 中 abort，此处检查可避免卸载后误发
实际写法示例
以下是一个简洁可靠的模式：
const controller = new AbortController();
if (controller.signal.aborted) {
// 可选：提前返回 Promise.resolve() 或 throw new Error('aborted before start')
return;
}
fetch('/api/data', { signal: controller.signal })
.then(r => r.json())
.catch(err => {
if (err.name === 'AbortError') return; // 显式忽略取消错误
throw err;
});
注意：不要仅依赖 catch 捕获 AbortError 来“事后清理”，因为请求本身可能已完成或部分完成；前置判断才是真正的优化关键。
常见误区提醒
几个容易踩的坑需要避开：
- 把
controller.signal提前赋值给变量再检查 —— 若 controller 后续被 abort，该变量引用的 signal.aborted 仍是最新值，没问题；但若 signal 被重新赋值（如误写成signal = new AbortSignal()），则失去关联 - 在异步回调里检查却没捕获最新 signal —— 确保闭包中引用的是同一个 controller 实例的 signal
- 以为检查了就不用在 catch 里处理 AbortError —— 仍需处理，因为 signal 可能在 fetch 调用后、响应前被 abort
