最近在做一个内部后台系统时，遇到一个非常典型的问题：用户在搜索框里输入关键字，每敲一个字母都会发一次请求。防抖加了，可当我快速切换筛选条件时，上一次较慢的请求仍然可能后返回，把新数据直接覆盖掉。为了修复这种数据错乱，我把AbortController翻出来重新研究了一遍，顺手解决了好几个困扰已久的请求取消、超时中断和内存泄漏问题。
这里说的AbortController，是浏览器原生提供的一个接口，专门用来“主动中止”一个或多个正在进行的网络请求。以前我们做请求取消，要么用XMLHttpRequest自带的abort()方法，要么用第三方库（比如 axios 里的CancelToken），但AbortController是标准方案，配合fetch使用非常顺手，在 React、Vue 这些框架里做竞态控制的场景下尤其好用。
如果你也在做前端请求管理，比如搜索框联想、上传下载取消、接口超时处理，或者正被“旧请求覆盖新数据”这种问题折磨，这篇文章会把AbortController的原理、用法、进阶封装和坑位一次性讲清楚。我不做理论念经，全程都是可以直接抄走的代码和实操结论。
1. 项目概述：为什么前端需要“请求中止”
在实际业务里，请求中止不是一个“用不到的高级功能”，而是每天都在发生的基础需求。只是很多团队一开始意识不到，等线上出了数据错乱、页面卡死才回头补课。
1.1 请求中止的三个核心场景
第一个场景是用户主动取消。比如用户上传一个 2GB 的视频文件到一半，发现选错文件了，这时候点击“取消”按钮，请求还在继续上传显然不合理。下载同理，用户点了“停止下载”，如果前端不把网络请求真正断开，浏览器底层连接会一直占着，尤其是在弱网环境下，体验会非常糟糕。
第二个场景是请求竞态。这是最常见的隐性 bug 来源。用户在搜索框输入“苹果”，又改成“苹果手机”，再改成“苹果手机多少钱”，防抖后可能同时发出 3 个请求，每个接口返回时间不一样，先发出的不一定先返回。如果最后一次输入对应的是最快的请求，那没问题；但更常见的是，第一次慢请求最后返回，把搜索列表错误地渲染成了旧结果。要解决这个问题，根本上就是要在发新请求时把上一个未完成的请求直接取消掉。
第三个场景是超时控制。移动端网络不稳定，接口 5 秒没响应，界面一直转圈，用户只能干等。常见的做法是搭配setTimeout在指定时间后主动中止请求，让界面进入“请求超时，请重试”的状态。以前想在 fetch 里做超时很不方便，有了AbortController就自然多了。
1.2 前端请求中止的技术演变
早年间大家都在用XMLHttpRequest，取消请求直接调用xhr.abort()就行。后来fetch成为标准，设计上更现代，但早期并没有内建的取消机制，导致很多团队不得不继续用 XHR，或者借助第三方库对请求做包装。axios 里的CancelToken曾经是比较流行的方案，但官方在后面版本中把它标记为“基于已废弃的 CancelToken API”，慢慢也开始推荐使用AbortController的signal方案。
从本质上讲，AbortController是一个“信号控制器”，它和网络请求本身解耦。换句话说，不只是 fetch 能用它，任何当你需要“通过外部信号中止某种异步操作”的场景，都可以挂一个AbortSignal上去。所以在 Node.js 的http模块、prisma 数据库操作、甚至一些流式处理里，也能看到AbortSignal的身影。
1.3 AbortController 的核心 API 与设计思想
AbortController本身只有两个核心成员：一个是signal属性，类型是AbortSignal；另一个是abort(reason?)方法，作用是触发中止信号。signal可以作为一个标记传入fetch(options.signal)，当abort()被调用时，浏览器会中断正在进行的请求，同时让 fetch 返回的 Promise reject，错误码是AbortError。
这种设计思路很像“广播机制”：controller 发出一个信号，所有注册到这个信号上的请求都能感知。一个 controller 甚至可以同时控制多个请求，比如批量上传 10 个文件时，一个“全部取消”按钮，就可以直接调一次abort()把 10 个请求全部取消。真正优雅的地方就在这里：请求方和取消方无需互相持有引用，只需要共享同一个signal对象即可。
2. 基础用法：从零到一掌握 fetch + AbortController
这一节先不整花活，把最基础的用法吃透。你后面遇到的大部分问题，追根究底都是基础用法没写好。
2.1 最小可运行示例：3 秒后自动取消请求
假设我们请求一个很慢的接口，比如 10 秒后才能返回，但我们希望最多等 3 秒。
const controller = new AbortController(); const signal = controller.signal; fetch('https://api.example.com/slow-data', { signal }) .then((res) => res.json()) .then((data) => { console.log('拿到数据', data); }) .catch((err) => { if (err.name === 'AbortError') { console.log('请求已被取消'); } else { console.error('请求出错', err); } }); // 3秒后主动取消 setTimeout(() => { controller.abort(); }, 3000);这段代码有一个很关键的细节：err.name === 'AbortError'。当请求被abort()中止时，fetch 抛出的错误并不是普通的网络错误，而是名字为AbortError的DOMException。如果你不区分这个错误类型，而是统一弹一个“网络异常”的提示，用户就会看到“我没取消请求，怎么就报错了”的诡异现象。
我在实际项目里见过不少团队，取消了请求但没有在 catch 里判断AbortError，结果每次输入关键字都被当作请求失败，前端弹了一堆错误提示。这个细节一定要记住。
2.2 给 signal 添加自定义监听：拿到取消节点
除了让 fetch 感知中止，我们还可以直接在signal上注册事件，这样在请求被取消的那一帧，就有机会同步更新 UI 状态、清理资源、打点上报。
const controller = new AbortController(); const { signal } = controller; signal.addEventListener('abort', () => { console.log('请求被中止，是否已中止：', signal.aborted); // 常用场景：关闭 loading、打日志、清空定时器 loading = false; }); fetch('/api/data', { signal });这里注意一点：signal事件里的event.type就是'abort'，但我们一般不需要 event 对象，直接读取signal.aborted就能判断当前状态。如果你有多个取消来源（比如不同的按钮都能取消同一个请求），这个事件回调也可以帮你区分“到底是谁触发了取消”。
一个小建议：监听事件时尽量加上{ once: true }，因为一个请求只会被取消一次，没必要让回调一直挂在 signal 上。不过abort事件本身也比较特殊，signal 被中止后事件不会重复触发，加不加 once 影响不大，但养成这个习惯没有坏处。
2.3 兼容旧版 axios：从 CancelToken 迁移到 signal
如果你还在用 axios 的老版本取消方案，建议尽快迁到AbortController。新版本 axios（1.x）已经支持直接传signal：
const controller = new AbortController(); axios.get('/api/user', { signal: controller.signal }); // 取消请求 controller.abort();它的内部原理是：axios 在发起 XHR 请求时，如果options.signal存在，会监听abort事件，一旦触发就调用底层的xhr.abort()。所以在 axios 里用AbortController，本质上依然是借助 XHR 的能力，但对外暴露的接口统一到了标准 API，API 设计更干净，也不需要再维护 CancelToken 那套自定义代码。
提示：如果你的项目里 axios 版本较老，无法支持
signal，建议至少升级到 1.x 再考虑批量替换。老项目如果不敢动依赖，也可以继续用 CancelToken 顶一阵，但要清楚它已经是废弃趋势，新代码尽量直接上AbortController。
3. 进阶场景实操：把 AbortController 用到真实业务里
基础用法学会之后，就该面对真正的业务场景了。这里我挑了几个高频又容易踩坑的案例，逐个拆解。
3.1 请求竞态：如何确保最后一次请求结果不被覆盖
搜索框联想、筛选列表、分页跳转，这类场景都会遇到竞态问题。我用一个SearchService类来封装“永远只保留最新请求”的能力：
class SearchService { constructor() { this.controller = null; } search(keyword) { // 每发起新请求前，取消上一次未完成的请求 if (this.controller) { this.controller.abort(); } // 创建新的控制器 this.controller = new AbortController(); return fetch(`/api/search?q=${encodeURIComponent(keyword)}`, { signal: this.controller.signal, }); } } const service = new SearchService(); // 模拟用户快速输入：输入 a -> ab -> abc service.search('a'); service.search('ab'); service.search('abc').then((res) => res.json()).then((data) => { console.log('最终结果', data); });当第三次调用search('abc')时，search('a')和search('ab')的请求都已经被中止。由于被中止的请求会 reject，如果在调用方没有 catch，控制台会报Uncaught (in promise) AbortError，所以调用方也需要统一 catch 一次。
这种模式的本质是“用取消代替忽略”。如果不取消，我们可能要用一个递增的requestId或者timestamp来判断响应是否是最后发出的请求，代码就会复杂得多。用AbortController直接从源头掐断旧请求，不仅省事，还减少了没必要的网络流量。
3.2 超时控制：两种写法与选型建议
超时是刚需，但写法上有讲究。我先给出最常用的手动写法，顺便说明为什么不建议所有场景都直接用原生的AbortSignal.timeout()。
第一种写法：setTimeout+AbortController。这是兼容性最好、也最灵活的做法。
async function fetchWithTimeout(url, timeout = 5000) { const controller = new AbortController(); const timer = setTimeout(() => { controller.abort(); }, timeout); try { const res = await fetch(url, { signal: controller.signal }); return await res.json(); } finally { // 无论成功失败，都要清掉定时器，避免定时器空转 clearTimeout(timer); } }第二种写法：AbortSignal.timeout(timeout)。如果你只需要一个单纯的超时取消，而且目标浏览器足够新，可以直接用这个静态方法：
const res = await fetch('https://api.example.com/data', { signal: AbortSignal.timeout(5000), });AbortSignal.timeout()的好处是内置了超时和取消逻辑，不需要手动创建 controller。但它的局限性也很明显：你不能在超时之外再额外手动取消同一个请求。比如“用户点击取消按钮 + 超时自动取消”这种组合场景，还是需要自己维护一个 controller。
我的建议是：简单请求用AbortSignal.timeout()快速解决；需要同时支持用户手动取消、还要把取消原因上报的场景，就老老实实用第一种手动写法。
3.3 文件上传取消：大文件也能随时中断
上传场景往往需要更精细的控制，比如显示进度、允许取消、取消后释放表单数据。我们来看一个完整的取消上传示例：
const controller = new AbortController(); const formData = new FormData(); const fileInput = document.querySelector('#fileInput'); formData.append('file', fileInput.files[0]); fetch('/api/upload', { method: 'POST', body: formData, signal: controller.signal, }) .then((res) => res.json()) .then((data) => { console.log('上传成功', data); }) .catch((err) => { if (err.name === 'AbortError') { console.log('用户主动取消了上传'); } else { console.error('上传失败', err); } }); // 点击“取消上传”按钮 cancelBtn.addEventListener('click', () => { controller.abort(); });很多同学会问：取消上传后，服务器那边怎么知道上传被中断了？答案是：浏览器会直接断开这个请求的 TCP 连接。但是，如果服务端没有监听连接中断事件，可能还会继续处理已经接收完的那部分数据。所以严格来说，取消上传的语义更多是“客户端不再发送剩余数据”，而不是“服务端立即丢弃数据”。
如果你要处理“取消后服务端必须停止处理”的场景，需要在服务端额外实现中断感知逻辑，比如监听req.on('close')或req.on('aborted')（Node.js 中），再做资源清理。
3.4 批量请求管理：一个 controller 中断多个请求
AbortController最爽的用法之一就是“一对多”。假设页面上有 3 个独立的图表接口，用户切换 Tab 后需要全部取消：
const controller = new AbortController(); const urls = ['/api/chart/a', '/api/chart/b', '/api/chart/c']; const tasks = urls.map((url) => fetch(url, { signal: controller.signal }).then((res) => res.json()) ); Promise.all(tasks) .then((results) => { console.log('三个图表的数据', results); }) .catch((err) => { if (err.name === 'AbortError') { console.log('批量请求已全部取消'); } }); // 用户切换 Tab 时，一次性取消所有请求 tabChangeBtn.addEventListener('click', () => { controller.abort(); });注意一点：当一个 signal 被中止后，这个控制器就不能再复用了。你如果想让用户切回来再次发起请求，必须重新new AbortController()，生成一个全新的 signal。所以实际业务里，我会把这个“新建 controller 并挂载到请求上”的动作封装成一个函数，避免在多个地方重复创建。
4. 常见问题与排查技巧实录
这部分是我整理的自留款，都是实际开发中容易被绊倒的细节。如果你使用AbortController时遇到诡异现象，大概率能在下面找到答案。
4.1 取消请求后，组件卸载还会触发 setState 警告
React 开发里常见这样的错误：组件卸载后，异步请求才回来，然后执行 setState，控制台给出“Can't perform a React state update on an unmounted component”的警告。有的同学用 AbortController 取消了请求，但还是有警告，原因是在catch中没有正确拦截 AbortError，错误继续外抛，被外层逻辑当成网络错误处理。
正确姿势是在请求函数里统一判断 AbortError，并且不要把取消当作异常抛给上层：
useEffect(() => { const controller = new AbortController(); fetch('/api/data', { signal: controller.signal }) .then((res) => res.json()) .then((setData)) .catch((err) => { // 取消的请求不处理，直接忽略 if (err.name === 'AbortError') return; setError(err); }); return () => controller.abort(); }, []);清理函数里执行controller.abort()后，fetch 的 Promise 会 reject，但因为我们已经在 catch 里把 AbortError 过滤掉了，所以组件卸载时不会触发任何 setState。
4.2 请求已经完成，再调用 abort 会怎样
有同学担心：接口已经返回数据了，这时候再执行controller.abort()，会不会报错？答案是：不会。对一个已经结束的请求调用abort()是安全的，abort()只是把 signal 的状态置为“已中止”，并且触发 abort 事件，但不会有任何异常抛出。
不过要注意，如果你的signal上挂了 abort 事件监听，请求已经成功后，事件依然会触发。所以如果你在 abort 回调里做了 loading 关闭操作，重复触发并不会导致逻辑错误，但如果你在 abort 回调里做了controller.abort()本身这种重复操作，就要小心死循环，建议用if (signal.aborted)提前判断。
4.3 内存泄漏：别让 signal 事件监听器一直挂在全局
AbortController本身很轻，但如果使用不当，还是会造成内存泄漏。最常见的场景是：在全局或长生命周期的对象里创建 controller，然后signal.addEventListener('abort', handler)，当模块要被销毁时，没有执行removeEventListener。
不过abort事件和普通事件略有不同，它只会触发一次。如果你确定 controller 和请求是同生共死的，泄漏概率很低。但如果你把signal当成一个通用“取消信号”传给多个模块，而模块只在特定生命周期内需要感知取消，那销毁时最好把监听器移除。
function TaskManager() { this.controller = new AbortController(); this.onAbort = () => { // 处理取消逻辑 }; this.controller.signal.addEventListener('abort', this.onAbort); this.destroy = () => { this.controller.signal.removeEventListener('abort', this.onAbort); this.controller = null; }; }4.4 取消请求后，控制台仍然报网络错误
有些浏览器环境下，请求被abort()中止后，控制台 Network 面板里会显示一个红色的 “failed” 或 “canceled” 请求。很多同学以为这是 bug，其实这是正常现象。从网络层面看，请求确实断了，显示 canceled 就是浏览器在告诉你“这个请求没正常完成”。
重点是：这个显示不会影响代码逻辑，只要你在 Promise 的 catch 里正确捕获了 AbortError，就不会把错误抛给用户。如果你非要让控制台干净一点，可以考虑在发起请求前做一层参数校验，把明显不需要发出的请求提前拦掉，但这不是必须的。
4.5 关于 AbortSignal.timeout 的兼容性补充
AbortController本身的兼容性已经很好了，主流的现代浏览器都支持。但AbortSignal.timeout()是相对较新的 API，在部分浏览器和旧版 Node.js 里并不存在。如果你要面向用户环境做兼容，建议自己写一个封装函数，避免依赖这个静态方法。
封装思路很简单：判断AbortSignal.timeout是否存在，不存在就用setTimeout手动 abort。
function createTimeoutSignal(timeout) { if (typeof AbortSignal.timeout === 'function') { return AbortSignal.timeout(timeout); } const controller = new AbortController(); setTimeout(() => controller.abort(), timeout); return controller.signal; }这样既利用了新特性，又保证了老环境下的可运行性。
4.6 服务端是否感知到请求被取消
不少后端同学会问：前端 abort 了，数据库操作会停吗？答案是：HTTP 请求层面连接会断，但服务端是否停止处理取决于你的服务端代码是否有感知断开的机制。比如在 Node.js 里，可以监听请求对象的close事件；如果是 Express + 数据库操作，在连接断开后继续执行数据库查询并不报错，但这部分开销已经产生了。
所以如果你的业务有“用户取消上传，服务端也要立刻停止处理大文件”这种强一致性需求，不能只依赖前端 abort，还需要后端配合。前端取消只是第一道防线，真正要做的，是控制好服务端的超时和断开处理逻辑。
5. 封装建议：一个通用的带超时 fetch 函数
把上面这些要点汇总，我这里分享一个我在项目里实际在用的封装函数。它兼顾了外部信号、超时中断、取消原因传递，代码不多，但很实用。
async function request(url, options = {}) { const { timeout = 10000, signal } = options; const controller = new AbortController(); // 外部已有 signal 时，同步外部 abort if (signal) { if (signal.aborted) { throw new DOMException('请求已被取消', 'AbortError'); } signal.addEventListener('abort', () => controller.abort(), { once: true }); } // 超时取消 const timer = setTimeout(() => controller.abort(), timeout); try { const res = await fetch(url, { ...options, signal: controller.signal, }); return res; } finally { clearTimeout(timer); } }这里有两个细节值得展开：
第一，为什么要传入外部 signal 时还新建 controller？因为 fetch 一次只能挂一个 signal。如果外部已经有一个signal，我们没法直接给它加超时，所以要在内部再建一个 controller，然后监听外部 signal 的 abort 事件，让内部 controller 跟着 abort。这样就实现了“多个取消来源”的组合。
第二，finally里的clearTimeout很关键。如果不清理定时器，即使请求 1 秒就返回了，那个setTimeout依然会在 10 秒后触发controller.abort()。虽然此时 abort 对已完成请求没有副作用，但定时器白跑一次，而且如果同一时间创建了大量请求，这些定时器会堆积，造成无谓的性能损耗。
这种封装能覆盖大部分业务场景：组件卸载时外部 signal 触发取消、统一超时防呆、以及用户手动 abort 的情况。调用方只需要传一个signal进去，拿到的是标准的 fetch Response，行为可预期。
6. 个人经验与一点小技巧
自己团队之前花了不少时间在请求竞态的坑里爬，最后把核心原因都归结为：前端没有统一的取消机制。引入AbortController之后，也不代表每个请求都应该挂它。我自己的原则是，只有这四类请求值得取消：
第一类是会互相覆盖的接口，比如搜索关键字、筛选条件、分页切换。这类接口用取消来保证“最后一次请求优先”很划算。第二类是耗时长的接口，比如文件上传下载，必须给用户随时中断的出口。第三类是组件销毁时会发回调的请求，必须用取消防止 setState 报错。第四类是对超时敏感的关键接口，比如支付状态查询、登录态校验，要用超时控制避免页面无限 loading。
如果请求本身是轻量的、返回极快、不具备覆盖关系的，硬套AbortController反而增加代码阅读成本。技术方案要为业务服务，不是每个任务都需要一个 controller。
最后分享一个小技巧。如果你正在用 React，可以写一个简单的 hooks 来复用取消逻辑：
function useAbortController() { const controllerRef = useRef(null); useEffect(() => { controllerRef.current = new AbortController(); return () => controllerRef.current?.abort(); }, []); const abort = () => controllerRef.current?.abort(); const signal = () => controllerRef.current?.signal; return { abort, signal }; }这个 hooks 的妙处在于：组件卸载时自动 abort，不用在业务代码里手动管理清理。请求发出前把 signal 传给请求函数，取消按钮直接调用abort()，逻辑非常清爽。踩过几次坑之后你会发现，请求中止本身不难，难的是把“中止后的各种分支”都处理干净，而AbortController恰好把这种分支收敛到了标准错误类型里，值得你在每个前端项目里认真用起来。
