Vue中AbortController调用导致内存泄漏的解决方案

问题代码示例

 复制代码<template>
  <div class="preview-text" v-loading="loading" element-loading-text="loading...">div>
template><style scoped lang="scss">
style>

内存泄漏分析

解决方案

 复制代码onBeforeUnmount(async () => {
  // 仅在loading为true时调用abort()，避免不必要的AbortError
  if (loading.value && props.abortController) {
    await nextTick();
    props.abortController.abort();
  }
});

先直接看代码。这段 onBeforeUnmount 里的逻辑，乍一看是标准的“组件卸载时取消请求”的做法，但问题就出在它那“无差别”的调用上。不管请求是成功还是失败，只要组件一卸载，就上去调一次 abort()。这就像在关抽屉时，非要再撕一张“取消条”贴在已经办完的材料上——而这纸条上还带着“当时办公室谁在场”的名单，结果整间办公室的人都被这张纸条勾住，走不了。

这件事到底怎么回事

我们可以把这个场景形象地理解为：关抽屉时，你非要再撕一张“取消条”贴在已经办完的材料上；这张纸条上还带着“当时办公室谁在场”的名单，结果整间办公室的人都被这张纸条勾住、走不了。

1. 表面现象

XML 预览弹框关闭后，即使手动触发垃圾回收，内存快照里依然能看到：

• 已经从页面中分离的 DOM 节点（Detached 的 el-dialog / preview-text）
• 背后还连着对应的 Vue 组件实例
• 引用链常经过：AbortController → AbortSignal → DOMException → ErrorStackData → Vue 的 effect scope

看起来像“弹框关了东西还在”，所以叫内存泄漏——至少是关不干净、回收不掉。

2. 真正的关键角色：abort() 造出来的“错误对象”

AbortController.abort() 不只是“告诉请求停一下”，浏览器还会：

1. 新建一个 DOMException（AbortError）
2. 挂到 signal.reason 上
3. 这个错误对象自带调用栈信息（堆里叫 ErrorStackData）

调用栈可以粗暴理解成：“是谁、在哪段代码路径上喊停的”的现场记录。
在 Chrome 里，这段记录有时会顺手抓住当时还活着的 Vue 组件“内部工作区”（effect scope / 闭包），而组件又抓着自己的 DOM。

所以：

3. 为什么“请求已经成功再关”也会中招？

很多人直觉会想：

因为：

• 进不进 catch，只说明“有没有一次失败的 Promise”
• 调不调 abort()，是另一回事

请求成功后你再关弹框，如果卸载时仍无脑：

 复制代码props.abortController.abort()

此时：

• 请求早结束了 → 不会进 catch（你的观察是对的）
• 但 abort() 照样会新建 AbortError 并挂到 signal 上
• 这个错误对取消请求没任何用处，却刚好够把 Vue 实例 / Detached DOM 钉住

一句话：

4. 为什么会勾住“已关闭”的弹框？（成环）

简化关系：

 复制代码AbortController（取消器）
    ↓
AbortError（abort 时创建，带调用栈）
    ↓
调用栈勾住 Vue 组件内部状态
    ↓
组件还能指回 AbortController（props）
    ↓
组件的 DOM（弹框内容）——页面上看不见了，但 JS 还以为有人在用

只要外面还有人握着这个 AbortController（哪怕只是一时、或工具/原生侧还挂着 signal），整圈都丢不掉 → 快照里就一直是 Detached 弹框。

5. 为什么 await nextTick() 曾经“看起来能修好”？

Vue 不会等异步的 onBeforeUnmount 跑完再拆组件。

• 立刻 abort：拆组件的过程中喊停 → 错误的调用栈更容易录进 Vue 正在拆的现场 → 容易钉死
• 先 nextTick 再 abort：组件先拆完，再喊停 → 调用栈不怎么沾那片 Vue 现场 → 看起来“好了”

所以 nextTick 是运气型的时间差，不是清晰的所有权设计。真正干净的是：没必要时不要 abort。

6. 为什么 onErrorCaptured 抓不到？

那是两套系统：

abort() 主要走 Signal / 请求 Promise，不是 Vue 组件异常冒泡。
请求失败进了你自己的 try/catch 被吞掉，Vue 更是无事可捕。
所以：堆里有 ErrorStackData，不等于组件报错了。

7. 你们最后为什么这样一改就好了？

 复制代码if (loading.value && props.abortController) {
  props.abortController.abort();
}

含义很直白：

• 还在加载（请求可能还在飞）→ 需要取消 → 才 abort()
• 已经加载完（你的主操作路径）→ 关弹框别 abort → 不再多余制造 AbortError → 钉链断掉

这就同时满足了：

1. 真要中途关掉时，还能取消请求
2. 看完再关时，不制造那场“无意义的 AbortError 挂钩”

8. 一句话总纲

造成这次问题的原因：

关 XML 弹框时（尤其在请求已成功之后）仍然调用 abort()，浏览器创建了带调用栈的 AbortError，并挂在 AbortController 上；调用栈通过 Vue 组件内部状态勾住了本应销毁的实例和 DOM，形成回收不掉的 Detached 节点。
它和“有没有进 catch”无关，本质是关抽屉时多余撕了一张会勾人的取消条。

有效做法： 只在仍在 loading、确实需要取消请求时 abort；请求已成功则直接拆弹框即可。