未完成的 Promise 本身内存占用小，真正危险的是其回调函数持续持有组件实例、DOM 节点等导致内存泄漏；应通过 AbortController 中止请求、用 ref 做存活检查、WeakMap 缓存、处理 unhandledrejection 等方式主动清理。
未完成的 Promise 本身不占多少内存，真正危险的是它所绑定的回调函数持续持有组件实例、DOM 节点、大型数据或闭包上下文，导致这些对象无法被垃圾回收。避免的关键不是“等 Promise 结束”，而是让 Promise 在不该执行时彻底停止副作用。
用 AbortController 主动中止 fetch 类请求
这是目前最可靠、标准化的做法，适用于所有支持 signal 选项的原生异步 API（如 fetch、WebSocket 构造函数等）：
- 在发起请求前创建
AbortController实例，并把它的signal传入fetch配置项 - 在组件卸载或逻辑终止时调用
controller.abort() -
fetch会立即 reject 并抛出AbortError，你可以在catch中静默处理，跳过后续setState或 DOM 操作
给 Promise 加上“存活检查”机制
尤其适合封装了自定义异步逻辑（比如轮询、重试、第三方 SDK 调用）的场景：
- 在组件内用
useRef（React）或ref（Vue）维护一个布尔标记，例如isMounted.current = true - 在 Promise 的
.then()和.catch()开头加判断：if (!isMounted.current) return - 在组件卸载钩子（
useEffect cleanup、onBeforeUnmount）中设为false
清理 Promise 工厂产生的长期引用
有些 Promise 不是“发一次就完”，而是由事件、定时器或状态变更反复触发，容易形成引用堆积：
立即学习“Java免费学习笔记（深入）”；
- 避免把
resolve或整个 Promise 实例存到全局变量、缓存 Map 或模块级对象里 - 如果必须缓存，用
WeakMap存储，键为当前组件实例或 DOM 元素，确保组件销毁后自动释放 - 对定时轮询类逻辑（如
setInterval(() => fetch().then(...))），必须同步管理 interval ID 和 abort controller，二者缺一不可
警惕未捕获拒绝引发的隐式引用滞留
Promise 被 reject 后如果没有 catch 或 try/catch，其 rejection reason（比如一个带堆栈和 DOM 引用的 Error 对象）可能因未被消费而滞留在引擎内部：
- 始终为 Promise 链末尾加上
.catch(console.error)或业务级错误处理 - 在开发环境启用
unhandledrejection监听，快速发现遗漏 - 不要在
catch中直接保存 error 对象到全局或长生命周期结构中，尤其当它包含element、response.body等大引用时
