手写一个限制最大并发数的异步任务调度器，怎么实现？

面试最常考的写法和它的输出

这道题常见的题面是：最多同时跑 2 个任务，依次加入耗时 1000、500、300、400 毫秒的任务，问打印顺序。

class Scheduler {
  constructor(limit) { this.limit = limit; this.running = 0; this.queue = [] }
  add(taskFn) {
    return new Promise((resolve, reject) => {
      this.queue.push({ taskFn, resolve, reject }) // 先排队，resolve 留到任务真正完成时再调
      this.run()
    })
  }
  run() {
    while (this.running < this.limit && this.queue.length) {
      const { taskFn, resolve, reject } = this.queue.shift()
      this.running++
      taskFn().then(resolve, reject).finally(() => { this.running--; this.run() }) // 结束就补位
    }
  }
}

const s = new Scheduler(2)
const wait = (ms) => () => new Promise((r) => setTimeout(r, ms))
const addTask = (ms, order) => s.add(wait(ms)).then(() => console.log(order))
addTask(1000, 1); addTask(500, 2); addTask(300, 3); addTask(400, 4)

2
3
1
4

为什么 add 要返回 Promise

调用方需要知道自己加进去的那个任务什么时候完成、结果是什么。但任务可能要在队列里等很久才开始，add 调用时根本拿不到结果。

所以 add 先返回一个「欠条」，也就是新建的 Promise，并把兑现欠条的 resolve 存进队列。等这个任务真的跑完，调度器再调用 resolve 把结果交出去。调用方只管 await s.add(task)，不用关心任务排了多久的队。

这也是为什么队列里存的是 taskFn 这个函数。函数只是「待办事项」，调用它才会真正发请求。如果调用方传进来的是 request() 返回的 Promise，请求在传参那一刻就已经发出去了，调度器再怎么排队也限制不了并发。

这份实现还有哪些漏洞要补

面试时写出上面的版本基本合格，能主动补上下面两点会加分。

任务同步抛错

如果 taskFn 本身不是 async 函数，执行时直接 throw，那么 taskFn().then(...) 这一行根本走不到 .then。这时 running 已经加了一，却永远不会减，调度器会少一个位置。改成 Promise.resolve().then(taskFn)，同步错误也会变成拒绝，统一走 finally。

任务一直不结束

某个请求挂住不返回，它占的位置就一直不释放。上限是 2 的话，挂住两个整个调度器就停了。实际项目里要给每个任务加超时，比如传一个 AbortSignal.timeout(ms) 给请求，超时就拒绝，位置自然被释放。

容易答错的地方

只在成功时计数减一

把 running-- 写在 .then 里，任务一失败，计数就永远少减一次。失败几次之后，调度器就不再执行任何任务。计数必须放在 finally 里，或者成功和失败两条路都写。

用 Promise.race 在外面凑并发

有人先把所有任务都调用一遍拿到 Promise，再用 Promise.race 等空位。这时任务早就全部开始了，限制的只是「等待」而不是「执行」，和题目要求不符。

忘了在任务结束后再调一次 run()

只在 add 里启动，队列里剩下的任务要等下一次 add 才会被取出来。没有新的 add，它们就永远在排队。

面试官还会怎么问？

把知识连起来