有了前面几篇文章所介绍的知识铺垫后，本系列最终篇，我们来封装一个能够指定并发上限的方法。
需求
先来过一下需求，封装一个异步方法 runWithConcurrency，如下：
async function runWithConcurrency(items, worker, maxConcurrency) {}该方法接收 3 个参数：
- items：要处理的任务列表
- worker：处理单个任务的异步函数
- maxConcurrency：最大并发量
先假设这个方法我们已经写好了，那么外部在使用的时候，大概是这么用的：
// 示例 1：模拟任务const items = Array.from({ length: 8 }, (_, i) => i + 1)
const worker = async (n) => { // 模拟耗时 200~800ms 的异步任务 await new Promise((r) => setTimeout(r, 200 + Math.random() * 600)) console.log(`处理完成：task=${n}`) return n * n // 返回结果}
const results = await runWithConcurrency(items, worker, 3)console.log('结果（顺序与输入一致）：', results)// 示例 2：真实网络请求（批量拉取）const urls = [ '/api/user/1', '/api/user/2', '/api/user/3', '/api/user/4', '/api/user/5',]
const fetchUser = async (url) => { const res = await fetch(url) if (!res.ok) throw new Error(`请求失败：${res.status}`) const data = await res.json() console.log('已获取：', url) return data}
const users = await runWithConcurrency(urls, fetchUser, 2)console.log('所有用户：', users)分析与实现
明确了需求后，接下来我们来逐步实现。假设外界调用的时候，是这么调用的：
await runWithConcurrency(urls, fetchUser, 2)那么这里传递的 2 是什么？
没错，是并发的上限，我们可以将其想象成有两个工人，如下图
┌──────────────────────────────────────────────────┐│ [任务五] [任务四] [任务三] [任务二] [任务一] │ ← i（下一个）└──────────────────────────────────────────────────┘ │ │ │ │ ▼ ▼ 工人 2 工人 1工人1 先领取了任务一，然后开始执行任务一
工人2 领取任务二，然后开始执行任务二
那么任务三交给谁呢？究竟由工人1 领取还是工人2 领取呢？
那得看哪一个工人的工作先完成，假设工人1 先完成了任务一，那么这个工人就去领取任务三；反之，如果是工人2 先完成了任务二，则是由工人2 去领取任务三。依此类推，后面的任务四、任务五也是这样，哪个工人手上没活了，就去领取下一个任务。这和我们现实生活中的场景，也是一致的。
这种模式在代码里对应的是：固定数量的工人 + 一个共享的“下一个任务”指针。
接下来落地到具体的代码。首先，我们来确定工人的人数：
async function runWithConcurrency(items, worker, maxConcurrency) { const n = Math.max(1, Math.min(maxConcurrency, items.length))}这里的 n 是实际工人的人数。有的同学会觉得很奇怪，为什么不直接用 maxConcurrency？因为：
- 工人数不能超过任务总数（否则有些工人一上来就没活干）
- 至少要有 1 个工人
接下来这 n 个工人开始干活：
const workers = []for (let k = 0; k < n; k++) workers.push(spawn())这里的 workers 用来收集每个工人（spawn()）返回的 Promise。一旦调用 spawn()，工人就会立刻去领取任务并开始执行；数组里收集的是“工人何时收工”的 Promise，而不是每个任务的 Promise。
紧接着是“工人如何领活儿”。该方法需要不断地把任务分配给工人，直到任务列表为空：
let i = 0 // 共享任务指针：指向“下一个要处理的下标”
async function spawn() { // 每个工人都需要不断地从任务队列中领取任务 while (i < items.length) { const idx = i++ // 领取当前要处理的任务下标 await worker(items[idx], idx) // 处理单个任务（工人内部串行） // 处理完继续回到 while，再领下一单；直到任务列表为空 } // 跳出 while：说明任务已经被领完，这个工人可以正常收工}这里要强调两点：
- 每个工人内部是串行的：比如工人 1 领了任务一，必须等这单完成（
await返回）后才能去领下一单。并发来自“有n个工人同时在干”，而不是让单个工人内部再并发。 - 共享指针是安全的：
const idx = i++这一步在同一次调用栈里是同步完成的（读取→使用→自增），不会被别的工人中途打断，因此不会出现两个工人领到同一单。真正“让出执行权”的地方发生在await worker(...)之后。
最后，等待所有工人完工，这里使用 Promise.allSettled：
await Promise.allSettled(workers)这一步不会启动任务，只是“在门口等所有工人跑完自己手上的任务”。
用 allSettled 的好处是：即便某个工人因为某一单失败而变成 rejected，也不会短路，其他工人仍会把剩下的活干完，更符合“批量任务尽量跑完”的诉求。
最终完整的代码如下：
async function runWithConcurrency(items, worker, maxConcurrency) { if (!items?.length) return
// i 是“下一个要被领取的任务索引”。多个工人共享这个变量。 // 在 JS 的单线程事件循环中，“读取 i -> 使用 i -> i++”这一小段代码在一次 // 宏/微任务中是原子的（不会被其他 JS 执行栈打断），因此可作为简单的任务分发指针。 let i = 0
// workers 用来收集每个“工人”的 Promise，后面用 allSettled 等待他们全部结束。 const workers = []
// spawn = 启动一个工人：不停从任务池里领取下一个索引并处理，直到没有任务可领 async function spawn() { // 当还有未处理的任务（i < items.length）就继续循环 while (i < items.length) { // 领取当前要处理的任务索引，然后自增以留给下一个任务 const idx = i++ // 执行该任务：必须 await，保证这个工人在“串行处理自己的任务队列” // 如果不 await，就会在单个工人内部产生更高的并发，超出 maxConcurrency 的约束 await worker(items[idx], idx) // 若 worker 抛错（reject），该 spawn() 的 Promise 会变为 rejected； // 但我们外层会用 Promise.allSettled，所以不会影响其它工人继续工作。 } // 退出 while：说明任务已经被领完，这个工人可以正常收工（resolve） }
// 计算实际需要启动的工人数： // - 不能超过任务总数（否则有些工人一上来就没活干） // - 至少 1 个 const n = Math.max(1, Math.min(maxConcurrency, items.length))
// 启动 n 个工人，每个工人都是一个独立的异步执行体（Promise） for (let k = 0; k < n; k++) workers.push(spawn())
// 等待所有工人“收工”。使用 allSettled： // - 不会因为某个工人失败而中断等待（all 会短路，allSettled 不会） // - 适合“多个任务相互独立，允许部分失败也要跑完”的场景 await Promise.allSettled(workers) // 函数到这里 resolve，表示全部任务都已尝试完成（成功或失败），所有工人均结束。}至此，带并发上限的并发执行方法就写完了。
写在最后
这一次我们实现了通用的 runWithConcurrency(items, worker, maxConcurrency)，用固定数量的工人配合共享游标分发任务，工人内部串行、整体受控并发；配套示例也证明它能稳妥跑完批量请求和本地批处理场景。
使用时有几处要点值得牢牢记住：
- 并发从调用
spawn()的那一刻就开始了，Promise.allSettled(workers)只是在门口把所有工人等到收工，并不会启动任务、更不会决定顺序； - 共享指针用的是
const idx = i++，在单线程调用栈里是同步完成的，不会出现两个人领到同一单； - 工人内部必须
await worker(...)，否则单个工人会把并发继续堆高，超出你的maxConcurrency。 - 另外，
workers装的是“工人的promise”而不是“每个任务的promise”，若需要拿回结果，可以在工人里按下标写回一个out[idx]再返回。空列表可以直接早退，maxConcurrency也最好做下限与取整的校验。
落到真实项目，还方法可以继续打磨：
- 给它包上超时与取消，必要时做重试与指数退避；
- 按需暴露进度回调与观测埋点，用数据调参；
- 在高压场景里引入优先级、背压和动态并发，保护上下游。
掌握并灵活运用这套基建，小到脚本批处理，大到服务侧限流，你的异步就能既稳又快。