问题代码示例
复制代码<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() 不只是“告诉请求停一下”，浏览器还会：
- 新建一个
DOMException（AbortError） - 挂到
signal.reason上 - 这个错误对象自带调用栈信息（堆里叫
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 抓不到？
那是两套系统：
| AbortError 挂在 signal 上 | Vue 的 onErrorCaptured | |
|---|---|---|
| 像什么 | 取消器上贴了张纸条 | 组件树报警器 |
| 要不要“抛给 Vue” | 不要 | 要 |
abort() 主要走 Signal / 请求 Promise，不是 Vue 组件异常冒泡。
请求失败进了你自己的 try/catch 被吞掉，Vue 更是无事可捕。
所以：堆里有 ErrorStackData，不等于组件报错了。
7. 你们最后为什么这样一改就好了？
复制代码if (loading.value && props.abortController) {
props.abortController.abort();
}
含义很直白：
- 还在加载（请求可能还在飞）→ 需要取消 → 才
abort() - 已经加载完（你的主操作路径）→ 关弹框别 abort → 不再多余制造 AbortError → 钉链断掉
这就同时满足了：
- 真要中途关掉时，还能取消请求
- 看完再关时，不制造那场“无意义的 AbortError 挂钩”
8. 一句话总纲
造成这次问题的原因：
关 XML 弹框时（尤其在请求已成功之后）仍然调用 abort()，浏览器创建了带调用栈的 AbortError，并挂在 AbortController 上；调用栈通过 Vue 组件内部状态勾住了本应销毁的实例和 DOM，形成回收不掉的 Detached 节点。
它和“有没有进 catch”无关，本质是关抽屉时多余撕了一张会勾人的取消条。
有效做法： 只在仍在 loading、确实需要取消请求时 abort；请求已成功则直接拆弹框即可。
