AbortController 取消 fetch 后为什么仍会收到响应：signal、Promise 与组件卸载边界

页面切换得很快时，旧页面发出的 fetch 可能还没返回，用户已经进入了下一页。此时调用 AbortController.abort() 能让浏览器取消请求，但它不会把已经排进微任务队列的 Promise 链“倒放”一遍；如果代码没有处理取消分支，旧请求仍可能继续触发日志、错误处理，甚至把结果写回已经卸载的组件。

正确的收口方式是两层一起做：用 AbortController 取消仍在途的网络请求，再用一个明确的状态门禁阻止过期 Promise 更新界面。

先把 fetch 的取消边界跑通

先看最小实验。AbortController 负责产生 signal，fetch 接收这个信号；调用 abort() 后，尚未完成的请求会在 Promise 链中走拒绝路径。这里的关键不是“网络线程是否瞬间消失”，而是后续代码是否把取消视为一种可预期状态。

const controller = new AbortController();
const { signal } = controller;

fetch('/api/profile', { signal })
  .then(response => {
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    return response.json();
  })
  .then(profile => {
    renderProfile(profile);
  })
  .catch(error => {
    if (error.name === 'AbortError') return;
    showNetworkError(error);
  });

controller.abort();

这段代码里有一条清晰的调用链：AbortController 产生 signal，fetch 监听它，取消后以 AbortError 结束。正常响应才会继续到 renderProfile；其他异常才交给 showNetworkError。如果把取消也提示成“网络错误”，用户切换页面时就会频繁看到无意义的错误提示。

为什么 abort 之后还可能看到 then 或 catch 的日志

abort() 只影响支持该信号且仍处于可取消阶段的请求。已经完成的响应不会被撤销，已经排队的回调也不会凭空消失。因此调试时看到 catch 日志并不代表取消失败，先检查错误名是否为 AbortError，再判断它是不是业务故障。

组件卸载后，加一道状态门禁

真实页面通常还要处理组件卸载：用户从“个人资料”切到“设置”时，旧页面的请求即使返回了，也不应该再调用旧页面的状态更新函数。下面用原生函数模拟组件生命周期，变量名保持短而明确。

function loadProfile() {
  const controller = new AbortController();
  let mounted = true;

  fetch('/api/profile', { signal: controller.signal })
    .then(response => response.json())
    .then(profile => {
      if (!mounted) return;
      renderProfile(profile);
    })
    .catch(error => {
      if (error.name === 'AbortError' || !mounted) return;
      showNetworkError(error);
    });

  return () => {
    mounted = false;
    controller.abort();
  };
}

const dispose = loadProfile();
dispose();

这里的时间线是：创建 AbortController，发出 fetch，页面卸载时先把 mounted 设为 false，再调用 abort()。如果响应恰好已经完成，回调仍可能执行，但会被 状态门禁 拦住；如果请求仍在途中，则会以 AbortError 结束。两道判断互相补位，不能只依赖其中一个。

控制器为什么不能跨请求复用

一个控制器对应一次请求更容易检查。若多个 fetch 共用同一个 signal，调用一次 abort() 会同时影响它们，代码阅读者很难判断哪个页面动作触发了取消。需要统一取消时，可以显式把请求分组；普通组件请求则保持一请求一控制器。

常见问题：取消请求时最容易误判什么

AbortController 能取消已经返回的响应吗？

不能。它主要作用于仍在进行且支持该信号的请求；响应已经完成后，代码仍需自行决定是否使用结果。

AbortError 要不要上报为网络故障？

用户主动离开页面造成的 AbortError 通常是正常控制流，可以静默结束；只有非取消异常才进入网络故障提示或上报。

只调用 abort()，不写 mounted 判断可以吗？

不建议。请求可能已经完成或回调已经排队，状态门禁能阻止过期结果写回页面。

把请求收口成可复查的检查清单

• 每次请求是否创建了自己的 AbortController，并把 signal 传给 fetch？
• catch 是否单独识别 AbortError？
• 组件卸载或页面切换后，结果回调是否经过 状态门禁？
• 调试日志是否记录了取消动作与真实网络异常，而不是只看“请求失败”？

把取消看成请求生命周期的一部分，代码就不会把“用户离开页面”和“接口真的坏了”混成一种错误。先收口 Promise，再保护状态更新，通常比不断给请求加重试更接近问题本身。