大型应用需建立统一取消策略体系，通过AbortController生命周期管理、可取消请求函数封装、状态管理跟踪及拦截重复/过期请求，将取消从补救手段变为设计契约。
在大型应用中，请求取消不能靠零散的 abort() 或 cancelToken 随处调用，而要形成统一、可追溯、可复用的取消策略体系。核心是把“谁发起、谁负责取消”变成“谁管理、谁统一调度”，避免内存泄漏和状态竞争。
统一 AbortController 生命周期管理
每个请求应绑定一个独立的 AbortController，但它的创建和销毁必须与业务上下文强关联。推荐按以下方式组织：
- 路由组件中：在
useEffect清理函数中调用controller.abort()，确保组件卸载时所有挂起请求被终止 - 自定义 Hook 中：返回的请求函数内部自动创建
controller，同时暴露cancel方法供外部主动触发（如用户点击“取消加载”） - 服务层（如 API 模块）：不直接暴露
signal，而是接收一个可选的signal参数，由调用方决定是否传入
封装可取消的请求函数
基础请求函数应支持传入 AbortSignal，并透传给 fetch。例如：
async function request(url, options = {}) {
const { signal, ...rest } = options;
const config = {
...rest,
signal,
headers: {
'Content-Type': 'application/json',
...rest.headers
}
};
const response = await fetch(url, config);
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return response.json();
}
这样上层可以自由组合取消逻辑，无需修改底层请求实现。
立即学习“Java免费学习笔记（深入）”；
结合状态管理做请求跟踪
大型项目常需知道“哪些请求还在跑”。可在全局状态（如 Redux 或 Zustand store）中维护一个请求 ID 映射表：
- 每次发起请求时生成唯一 key（如
GET:/api/users?role=admin），存入 map 并关联controller - 提供
cancelByPattern(pattern)或cancelAll()方法批量取消 - 配合 Loading 状态使用：map 非空即显示全局 loading，清空后自动隐藏
拦截重复或过期请求
取消不只是“手动点一下”，更要预防无效请求：
- 对相同 URL + 参数的请求，若已有进行中实例，直接复用其 Promise 或取消旧请求、发起新请求
- 为搜索类请求加防抖，延迟发送；延迟期间新请求到来则取消前一个
- 设置请求过期时间（如 10 秒未响应则自动 abort），避免卡死
不复杂但容易忽略。关键是把取消从“补救手段”变成“设计契约”——每个请求从诞生起就明确自己的生命周期边界。
