pending promise 本身不导致内存泄漏，但若持有闭包、dom、大对象或 async 上下文等强引用，则会阻碍 gc；需通过 devtools 检查 retainers、避免悬空链、注入超时与取消机制来防控。
Promise 链长期处于 pending 状态，本身不会直接导致内存泄漏；但若它持续持有对闭包、DOM 引用、大型数据结构或 async 函数上下文的强引用，就可能让本该被回收的对象滞留内存。识别这类问题，关键不是看“pending”本身，而是看“谁在等待它”，以及“等待者是否还被其他活跃对象引用”。
观察 Promise 的引用链与持有者
一个 pending Promise 是否危险，取决于它是否被可达（reachable）的变量或回调所引用：
- 检查是否有外部变量直接赋值了该 Promise（如 let p = new Promise(...)），且该变量未被释放；
- 确认 Promise 的 .then() 或 .catch() 回调中是否捕获了外层作用域的大对象（如组件实例、缓存 Map、全局状态）；
- 特别注意 async 函数中 await 了一个永不 resolve 的 Promise：此时 async 函数的执行上下文（含参数、局部变量、词法环境）会被该 Promise 的内部回调引用，只要 Promise 不决议，上下文就无法被 GC。
用开发者工具定位滞留的异步上下文
Chrome DevTools 的 Memory 面板可辅助识别：
- 录制一次操作后，点击 Collect garbage，再拍一张 Heap Snapshot；
- 在 Class filter 中搜索 Promise，筛选出大量状态为 pending 的实例；
- 对任一 pending Promise 右键 → Reveal in Console，再在控制台执行 console.dir(p)，查看其 [[PromiseState]] 和 [[PromiseResult]]；
- 切换到 Retainers 标签页，看它被哪些对象持有（例如某个 class 实例、event listener、timer callback）——这些就是潜在的滞留源头。
检测未处理拒绝与悬空链式调用
未决议常伴随未处理的拒绝或中断的链式调用，加剧内存滞留风险：
- 监听全局 unhandledrejection 事件，及时捕获漏掉的错误分支；
- 避免写形如 promise.then(fn1).then(fn2) 却不加 .catch() 的链：一旦 fn1 抛错且无 catch，整个链断裂，后续 Promise 可能变成 unreachable pending；
- 慎用 Promise.all([...]) 包裹不确定是否完成的 Promise 数组——其中任一 pending，整体就永远 pending，且全部成员都难以被 GC。
主动注入超时与取消机制
把“可能永远 pending”的操作显式转为“有界等待”，从根源上规避滞留：
- 用 AbortSignal.timeout(ms) 包装 fetch 或其他支持 signal 的 API；
- 自定义封装 timeout 工具函数：Promise.race([p, new Promise((_, reject) => setTimeout(() => reject(new Error('timeout')), 5000))])；
- 对长周期任务（如轮询、WebSocket 心跳），使用可取消的 Promise 封装器，确保 cancel 调用能清理所有关联引用（包括定时器、事件监听器、async 上下文）。
