Promise构造函数内大对象被executor闭包捕获后，会固化在Promise实例引用链中，导致所有后续then回调被动继承并长期持有该对象，无法被GC回收。
Promise 构造函数内部发生的内存泄漏，会直接污染整个 Promise 链的闭包环境——不是“影响后续 then”，而是让所有后续 then 回调**被动继承并长期持有泄漏源**，导致本该释放的对象无法被回收。
泄漏源头固化在 Promise 实例的闭包链中
Promise 构造函数执行时，其 executor 函数（即 new Promise((resolve, reject) => {...}) 里的回调）会立即同步运行，并形成一个独立作用域。如果这个作用域里定义了大对象（如 const hugeData = new ArrayBuffer(50MB)），且被内部的 resolve 或异步操作间接捕获，那么该对象就会成为 Promise 实例内部状态的一部分。
即使你后续只写 .then(() => {})，这些回调函数在创建时，仍会通过 Promise 内部的微任务队列机制，隐式绑定到原始 Promise 的上下文链中。V8 引擎不会为每个 then 新建干净的作用域，而是复用或延伸 executor 创建的闭包引用链。
- executor 中未释放的大数组、缓存对象、DOM 引用，一旦被
resolve的值或异常堆栈携带，就变成 Promise 实例的“不可达但强引用”状态 - 后续所有
then回调，哪怕空函数() => {}，只要 Promise 实例本身未被 GC（比如还挂在某个变量或全局缓存里），就持续拖住整个引用链 - 典型表现：Chrome DevTools 的 Memory 面板中，
queryObjects(Promise)显示大量存活 Promise 实例，每个都关联着数 MB 的ArrayBuffer或hugeList
then 回调自身也可能加剧泄漏
Promise 链中的 then 回调若无意中捕获外层大对象，会叠加泄漏层级：
立即学习“Java免费学习笔记（深入）”；
-
const config = { data: new Array(1e6) }; fetch('/api').then(res => res.json()).then(json => console.log(config.data.length))→config被闭包锁定，即使fetch已完成 - 返回新 Promise 的
then（如then(() => Promise.resolve())）会创建新 Promise，但旧 Promise 实例及其闭包仍存在，直到所有链上回调执行完毕且无外部引用 - 未处理的 rejected Promise 会保留错误堆栈，而堆栈中可能包含被捕获的大型上下文对象
泄漏不因链结束而自动清理
很多人误以为 Promise 链执行完就“释放干净”，但事实是：
- Promise 实例一旦创建，其内部状态（
[[PromiseState]]、[[PromiseResult]]、[[PromiseFulfillReactions]]等）由引擎管理，不会因链终止自动销毁 - 只要有一个变量（包括闭包、WeakMap、事件监听器、甚至控制台里刚打印过的 Promise）还持有对它的引用，它和它所闭包的全部数据就无法回收
- 尤其危险的是：将 Promise 存入全局 Map 缓存、组件实例属性、或作为模块导出常量，等于给泄漏源加了一把永久锁
如何切断泄漏传播
关键不是避免使用 then，而是控制 executor 和回调中的引用生命周期：
- 在 Promise executor 中，只保留真正需要传递给
resolve的最小数据；大对象用URL.createObjectURL()或分块处理，避免直接塞进resolve(value) - 链式
then中，显式解除对外部大对象的依赖：then(data => ({ id: data.id, name: data.name }))，而不是then(data => process(data))（其中process可能隐式持有data全量） - 组件或模块销毁时，主动清空 Promise 引用：
pendingRequest = null；对长期存在的 Promise 链，考虑用AbortSignal中断并置空相关闭包变量 - 用
performance.memory监控堆增长，配合 Chrome 的 Allocation instrumentation on timeline，定位哪个 Promise executor 分配了异常内存
