通过调用 abortcontroller 实例的 abort() 方法并传入对应的 abortsignal，可以立即中断正在进行的 fetch 请求。具体做法是在发起请求前创建控制器，将 signal 作为配置项传递给 fetch，并在需要取消时调用 abort()，此时请求会抛出 domexception 异常，从而阻止后续的数据处理逻辑执行。
如何正确初始化 AbortController 以支持取消
在 JavaScript 中，AbortController 是管理请求生命周期的核心对象。要支持取消操作，必须在请求发起前实例化该控制器，并将其生成的 signal 属性绑定到 fetch 请求的配置对象中。这样浏览器网络层就能监听信号状态，一旦信号被中止，网络连接会立即关闭。
const controller = new AbortController();
const signal = controller.signal;
fetch('/api/sensitive-data', { signal })
.then(response => response.json())
.then(data => console.log(data))
.catch(error => {
if (error.name === 'AbortError') {
console.log('Request cancelled');
} else {
console.error('Fetch failed:', error);
}
});
// 稍后调用取消
controller.abort();上述代码展示了标准的初始化流程。首先创建 controller，获取 signal。在 fetch 调用中，通过 options 参数传入 signal。当调用 controller.abort() 时，Promise 链中的 catch 块会捕获到一个名为 AbortError 的异常。开发者需要在 catch 块中区分 AbortError 和其他网络错误，以避免误报。这种机制确保了在数据预脱敏请求尚未完成或返回敏感数据之前，连接被强制切断，防止内存泄漏或不必要的数据暴露。
立即学习“Java免费学习笔记（深入）”；
掌握 ES6+ 特性，包括 async/await、解构、扩展运算符、箭头函数、Promise、模块、迭代器、生成器以及函数式编程模式，编写简洁高效的 Java
如何处理取消后的资源清理与状态同步
取消请求不仅仅是停止网络传输，还涉及前端状态的同步和潜在的资源清理。当请求被取消后，相关的 UI 状态（如加载指示器）应及时重置，避免界面卡在“加载中”状态。此外，如果请求关联了定时器或其他异步任务，也需要一并清理，以防止内存泄漏。
let currentController = null;
function fetchData() {
// 如果有正在进行的请求，先取消
if (currentController) {
currentController.abort();
}
currentController = new AbortController();
const signal = currentController.signal;
showLoading(true);
fetch('/api/sensitive-data', { signal })
.then(res => res.json())
.then(data => updateUI(data))
.catch(err => {
if (err.name !== 'AbortError') {
handleError(err);
}
})
.finally(() => {
showLoading(false);
// 可选：清理引用，允许 GC 回收
if (currentController && !signal.aborted) {
currentController = null;
}
});
}这段代码演示了在实际应用中如何处理取消逻辑。每次调用 fetchData 时，都会检查是否存在旧的 controller，如果存在则先 abort，确保同一时间只有一个请求在进行。这在用户快速切换页面或重复触发请求时非常有用。finally 块用于确保无论请求成功、失败还是被取消，加载状态都会被重置。通过维护一个 currentController 引用，可以实现请求的竞态条件控制，避免旧请求覆盖新请求的结果。对于预脱敏数据请求，这种模式能有效防止在用户离开页面或取消操作后，后台仍在处理敏感数据并尝试更新已卸载组件的状态。
基于 AbortError 异常的具体处理策略
当请求被取消时，fetch API 会抛出一个 TypeError 或 DOMException，其 name 属性为 'AbortError'。这是判断请求是否被主动取消的关键依据。在处理预脱敏数据的场景中，忽略这个特定的错误非常重要，因为取消通常是预期内的行为，而非真正的网络故障。
在 catch 块中，必须显式检查 error.name === 'AbortError'。如果不做此检查，普通的错误处理逻辑可能会将取消操作记录为系统错误，导致监控告警误报或日志污染。此外，由于 AbortError 是同步抛出的（在 Promise 链中表现为 rejected），它不会触发 then 块，直接进入 catch。因此，任何依赖于请求成功返回后的副作用代码（如更新全局状态、发送分析事件等）都不应放在 finally 中无条件执行，而应通过标志位或状态检查来确保只在非取消情况下执行。例如，可以在 fetch 前设置一个 isCancelled 标志，或在 catch 中判断后跳过后续逻辑。这种精细的控制确保了应用程序在取消请求后保持状态一致，不会因残留的异步回调而产生不可预测的行为。
