await 永久 pending 的 promise 本身不导致内存泄漏，真正风险在于闭包中持有组件实例、dom 节点或大对象等强引用未释放；应避免直接访问 this/state/props，使用 abortcontroller 中断请求，用 weakmap 管理 resolve 引用，并加超时保护与监控。
await 一个永久 pending 的 Promise 本身不会造成内存泄漏，真正危险的是它背后隐含的外部强引用——比如闭包捕获了组件实例、DOM 节点或大体积数据，而这些引用又没被及时断开。
检查是否持有长生命周期对象的引用
如果 await 的 Promise 回调里用了 this、ref.current、largeArray 或 el，即使 Promise 永不完成，这些对象也会被锁住无法回收。
- 避免在 then 或 await 后直接访问组件 state/props；加卸载判断（如 isMounted）或用 AbortController 配合 signal.aborted 检查
- 不要在闭包中长期持有未序列化的响应体、图片 blob、大型数组；必要时 shallow clone 或只存 ID
- React 中尤其注意：useEffect 内部的 async 函数若直接 setState，必须确保组件仍挂载
主动中断网络类 pending 操作
fetch、XMLHttpRequest 等底层资源不释放，会拖慢 GC，也容易导致连接堆积。AbortController 是目前最可靠的标准方案。
- 创建 controller：const controller = new AbortController()
- 请求时传入 signal：fetch('/api', { signal: controller.signal })
- 组件卸载或超时时调用 controller.abort()，Promise 会以 AbortError 拒绝，自动清理底层 socket 和监听器
- 注意：需在 catch 中过滤掉 AbortError，避免误报
手动管理自定义 Promise 的 resolve/reject 引用
当你 new Promise 并把 resolve 存到数组、this 上或全局队列里，就相当于人为延长了它的生命周期。
- 别直接挂 this.resolve = resolve；改用 WeakMap 关联上下文：pendingResolves.set(instance, resolve)
- 在组件销毁、超时或条件满足后，显式清除引用：resolveList.splice(i, 1) 或设为 null
- 给关键 Promise 加超时保护：setTimeout(() => reject(new Error('timeout')), 30000)
监控和暴露潜在泄漏点
未处理的 rejected Promise 不会卡内存，但可能掩盖资源未释放的问题，比如没关 WebSocket、没释放 IndexedDB transaction。
- 浏览器中监听 unhandledrejection，记录错误并检查关联资源状态
- Node.js 中监听 process.on('unhandledRejection', …)，配合资源池日志做交叉验证
- 开发阶段启用 Chrome DevTools 的 Memory tab，录制堆快照对比“挂载→卸载→等待后”的对象留存情况
