PriorityExecutor 是可控异步调度器，需用 WeakMap 管理 AbortController 避免内存泄漏，按字符串优先级（critical/normal/idle）调度，任务须支持取消且上下文通过参数传入、finally 清理。
手动实现一个同时支持优先级队列和自动垃圾回收的高阶 Promise 执行器，本质上是构建一个可控的异步任务调度器——它不依赖 Promise.all 或 Promise.race 的扁平行为，而是能按权重执行、及时释放已完成任务的引用。核心难点不在“实现 Promise”，而在“控制生命周期”与“避免内存滞留”。
为什么不能直接用 Promise 构造函数 + 数组堆管理优先级
单纯用 Array.sort() 维护任务队列，在高频率 push/resolve 场景下会快速退化（O(n log n) 每次插入），且无法感知任务是否已被取消或超时；更关键的是，原生 Promise 实例一旦创建，其闭包捕获的上下文（如大对象、DOM 引用）不会因外部变量置 null 而自动释放——这就是垃圾回收失效的根源。
- 必须用
WeakMap关联任务元数据与 Promise 实例，避免强引用滞留 - 优先级不能只靠数字比较：需区分“紧急调度”（如 UI 响应）和“后台批处理”（如日志上报），建议用字符串等级（
'critical'/'normal'/'idle'）配合数值权重 - 每个任务需自带
abortSignal或显式cancel()方法，否则无法在 resolve 前中断并解绑监听器
PriorityExecutor 的构造与任务注册必须分离生命周期控制
构造器只初始化调度器状态（如 pendingQueue、runningCount），任务注册方法（如 submit()）才负责生成可取消的 Promise 封装。重点在于：Promise 的 executor 函数体内不能直接持有对外部大对象的引用，所有上下文应通过参数传入，并在 finally 块中显式清理。
const executor = new PriorityExecutor({ maxConcurrency: 3 });
executor.submit(
() => fetch('/api/data').then(r => r.json()),
{ priority: 'critical', id: 'user-profile-load' }
).then(data => {
// 处理结果
}).catch(err => {
// err 可能是 AbortError，非网络错误
});
// 内部实际执行类似：
// const controller = new AbortController();
// fetch(url, { signal: controller.signal })
// .finally(() => weakMap.delete(controller)); // 防止 signal 滞留
- 每个
submit()返回的 Promise 必须绑定独立的AbortController，且该 controller 存于WeakMap中，键为 Promise 实例本身 -
id字段非必需，但强烈建议提供——用于后续cancelById('xxx')或监控面板过滤 - 不要在
submit()的回调函数里直接访问this或长生命周期组件实例；改用闭包参数传入所需数据
自动垃圾回收真正起效的三个条件
所谓“自动”，是指无需调用方手动 delete 或 null，只要任务完成/取消，其关联资源就可被 GC 回收。但这需要同时满足：
- Promise 实例本身不再被任何作用域变量、事件监听器、定时器回调引用（包括开发者忘记移除的
addEventListener） - 任务携带的 payload（如上传文件的
Blob、Canvas 的ImageData）未被其他地方强持有 -
WeakMap中存储的控制器、日志句柄等辅助对象，其 key（即 Promise 实例）一旦不可达，value 自动消失
常见陷阱：catch 块中把错误对象赋给全局 window.lastError；或在 Vue/React 组件中将任务 Promise 存在 data 或 useState 里却不清理；又或者用 setTimeout 模拟重试但没清除定时器 ID。
优先级调度和 GC 不是开关式功能，它们生效的前提是你放弃对 Promise 实例的随意持有——一旦你把它塞进某个长期存活的对象属性里，再精巧的 WeakMap 也救不了内存泄漏。
