应使用 AbortController 主动终止未完成请求，React/Vue 中在卸载钩子调用 controller.abort()，避免闭包引用、全局缓存及第三方库信号透传失效导致的内存滞留。
检测并清理未取消的网络请求，关键在于识别“已发起但未完成、且响应已无意义”的请求，它们会持续持有回调函数、上下文对象甚至大型数据结构，阻碍垃圾回收。
怎么发现未取消的请求在偷偷吃内存
这类泄漏不像事件监听器那样直观可见，需结合运行时行为和工具交叉验证：
- 打开 Chrome DevTools → Network 面板，勾选 “Preserve log”，反复触发页面切换或组件销毁操作，观察是否有请求状态长期卡在 Pending 或 (cancelled) 之后仍出现在后续快照中——注意：显示 cancelled 不代表资源已释放，只是连接中断，JS 回调可能仍在内存里
- 切到 Memory 面板，手动 GC 后拍堆快照，筛选构造函数名含 Promise、AbortController、fetch 或你封装的请求类（如 ApiService），看其数量是否随操作次数阶梯式增长
- 在控制台执行 performance.memory?.usedJSHeapSize，多次进入/退出同一模块，若数值只升不降，且排除了 DOM 和事件因素，就要重点查请求生命周期
现代标准做法：用 AbortController 主动终止
这是目前最可靠、浏览器原生支持的取消机制，所有主流 fetch 实现都兼容：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 发起请求时传入 signal：
const controller = new AbortController();<br>fetch('/api/data', { signal: controller.signal })<br> .then(r => r.json())<br> .catch(err => { if (err.name === 'AbortError') return; /* 处理真实错误 */ }); - 在组件卸载、路由离开或用户主动取消时调用：
controller.abort(); // 一次调用，自动拒绝 Promise 并清理内部引用 - 避免重复创建 controller：每个请求应独享一个 controller，不要复用；也不要在 abort 后再次调用 abort()（安全，但无必要）
框架场景下的统一管理技巧
不依赖手写逻辑，把取消动作融入生命周期钩子：
立即学习“Java免费学习笔记（深入）”；
-
React（useEffect）：
返回的清理函数里调用controller.abort()，确保组件 unmount 时触发 -
Vue（onBeforeUnmount）：
在钩子内检查 controller 是否 active，是则 abort -
自定义 Hook / Service 层：
封装 request 函数，自动创建 controller，并暴露 cancel 方法；或返回带 .cancel() 的 Promise 包装对象（如 axios 的 CancelToken 已淘汰，推荐迁移到 AbortSignal）
容易被忽略的隐藏引用点
即使调用了 abort，以下情况仍可能导致内存滞留：
- 请求成功后，.then() 回调里把响应数据存进全局缓存（如
window.cache = response），且没做清理 - 使用 async/await 时，在 try/catch 外部声明了大对象，被闭包捕获进未完成的 Promise 链
- 第三方请求库（如旧版 axios）未正确透传 signal，或内部缓存了未 resolve 的 Promise 实例
- 请求失败后，错误处理函数里意外保留了 this 上下文（如 class 成员方法作为回调），而该实例本该被销毁
