promise的微任务机制是现代javascript并发控制的底层基础，通过事件循环中微任务队列的确定性执行顺序实现链内有序、链间并发的调度；asyncpool等工具正是基于此机制，用running计数与finally接力实现轻量精准的并发节流。
Promise 的微任务机制是它能支撑现代 JavaScript 并发控制的底层基础。不是靠“多线程”或“抢占式调度”，而是靠事件循环中微任务队列的确定性执行顺序，让异步任务既能并发发起，又能受控调度、有序收尾。
微任务队列决定 Promise 回调的执行时机
每次 Promise 状态改变（resolve 或 reject），其关联的 .then、.catch、.finally 回调不会立刻运行，而是被推入微任务队列（Microtask Queue）。这个队列在当前宏任务（如脚本执行、setTimeout 回调）结束后立即清空——所有已排队的微任务按先进先出顺序依次执行，中间不插入任何宏任务。
- 这保证了 Promise 链内部的执行顺序严格可控：比如
Promise.resolve().then(a).then(b)中，a 一定在 b 之前执行 - 但多个独立 Promise 链之间没有先后约定：它们的微任务是并行加入队列的，执行顺序取决于各自 resolve 的快慢和引擎调度细节
- 正是这种“链内有序、链间并发”的特性，为上层实现并发控制（如限制同时运行请求数）提供了可预测的调度锚点
并发控制本质是“节流微任务的触发节奏”
所谓并发控制，并非阻止 Promise 创建或执行，而是控制 多少个 Promise 的 executor 函数能同时进入运行状态。因为每个 executor 是同步执行的（例如发起一个 fetch 请求），而后续的 then 回调才进微任务队列。所以关键在于：不让过多的 executor 在同一时刻被调用。
- 典型做法是维护一个“运行中任务计数器”和一个待执行任务队列
- 每次有新任务入队，先检查当前运行数是否小于限制值；若未达上限，则立即执行该 Promise 的 executor；否则暂存等待
- 当任一任务完成（无论成功或失败），在它的 .finally 里递减计数，并从队列中取出下一个任务执行 —— 这个“取出并执行”动作本身又会触发新的微任务链
- 整个过程不依赖定时器或轮询，完全由 Promise 自身的微任务流转驱动，轻量且精准
asyncPool 是微任务机制落地的典型范式
asyncPool(limit, array, iteratorFn) 这类工具函数，就是把上述逻辑封装成可复用的模式。它不重写 Promise，只是巧妙利用其状态流转和微任务调度：
- iteratorFn 返回的每个 Promise，代表一个独立异步操作（如 API 调用）
- pool 内部用 递归调用 .then/.catch/.finally 实现任务接力，而不是用 for 循环直接遍历数组
- 所有“启动新任务”的逻辑都放在 已完成任务的 finally 回调中，确保只有前序资源释放后，才触发下一轮 executor 执行
- 最终返回的结果数组保持原始顺序，靠的是为每个任务记录索引，并在 resolve 后按序填充结果，而非依赖执行顺序
手写简易并发调度器的关键节点
一个最小可行的并发控制器只需关注三个动作：入队、执行、接力。它不需要复杂状态机，核心就藏在 Promise 的微任务行为里：
- 用 let running = 0 跟踪当前活跃任务数
- 定义 next() 函数：若
running 0，则取出一个任务执行，并running++ - 每个任务的 .finally(() => { running--; next(); }) 构成自动接力闭环
- 所有任务通过 Promise.all(results) 汇总，既保留并发效率，又统一收口
