javascript异步并发瓶颈本质是多任务争抢资源，需通过分片+闭包实现状态隔离、错峰启动+动态退避平滑压力、共享信号+运行时调节实现动态并发控制。
JavaScript 异步并发瓶颈的本质，不是“能不能发请求”，而是“同一时刻有多少任务在争抢资源”——包括主线程执行时间、网络连接数、内存占用、服务端限流响应等。真正有效的负载分流，不靠堆机器或加带宽，而是在代码层实现时间错峰、资源均摊、失败隔离。
用分片 + 闭包固化上下文，让每个任务自洽运行
把大批量任务切分成小块（如每 5 条一组），再为每组创建一个独立执行单元：
- 每个分片函数通过闭包捕获自己的数据、重试次数、起始时间、是否完成等状态，互不干扰
- 即使某一片 fetch 失败或超时，也不会中断其他片，视觉上就像“自动绕开拥堵路段”
- 避免全局共享状态带来的竞态风险，比如多个任务同时修改同一个计数器
错峰启动 + 动态退避，把压力从“瞬间爆发”变成“平滑铺开”
10 个请求在 10ms 内齐发，和间隔 200ms 依次发出，对服务端和浏览器的体验差异巨大：
- 根据分片索引计算初始延迟：delay = index * 200 + Math.random() * 100
- 每次重试都基于该基础 delay 做指数退避（如 ×1.5），而不是所有任务共用一套固定节奏
- 配合 Promise.delay 或 setTimeout 触发实际请求，自然形成时间维度上的软负载均衡
共享控制信号 + 运行时调节，让系统能“呼吸”
真正的负载分流需要响应变化，比如用户切到后台、网络变弱、或手动暂停：
- 定义一个轻量对象（如 { isPaused: false, maxConcurrency: 3 }），所有分片闭包都引用它
- 每个任务执行前检查 isPaused；执行中读取 maxConcurrency 控制并行数
- 外部只需修改这个对象，所有正在运行和排队的任务立刻感知，无需重建或重启
动态腾挪式并发控制，比静态排队更省资源
限制并发数 ≠ 把任务塞进队列慢慢等。关键在于“有空位才放行”：
- 维护 running 计数器和待执行队列，任务 resolve 后立即检查队列，有空位就拉一个进来
- 比起 Promise.all 批量发起再统一 await，这种方式能持续利用空闲资源，吞吐更高
- 配合 p-limit 等成熟库可快速落地，但理解其“完成一个、释放一个、补进一个”的逻辑更重要
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
