JavaScript宏任务队列按FIFO顺序执行，每次仅处理一个任务，天然互斥；并发控制需在异步操作发起时实现，如限流请求、分批执行或使用async-pool，而非依赖队列本身。
JavaScript 宏任务队列本身不“管理”并发，它只是按顺序排队、一次取一个任务执行——真正的并发控制要靠开发者在宏任务之外主动设计。
宏任务队列不支持并发执行
宏任务队列是先进先出（FIFO）的线性结构，事件循环每轮只取出并执行队首的一个宏任务。即使同时注册了 10 个 setTimeout(fn, 0)，它们也严格按注册顺序排队，前一个没执行完，后一个绝不会启动。这意味着：
- 宏任务之间天然互斥，不存在“多个宏任务同时运行”的情况
- 所谓“并发请求”，实际是多个异步操作（如 fetch）几乎同时发起，但它们的回调仍作为独立宏任务排队等待
- 浏览器或 Node.js 不会为宏任务做资源分配或限流，全靠你代码逻辑约束
并发控制必须落在宏任务触发前
真正需要限流的环节，不是宏任务队列本身，而是异步操作的发起时机。比如发 100 个 API 请求，关键不在“回调怎么排”，而在“请求本身别一股脑全发出去”。常见做法：
- 用函数工厂封装请求：() => fetch('/api/user/1')，而不是直接调用 fetch()
- 把这批函数放进队列，每次只触发固定数量（如 3 个），等其中某个完成再补新任务
- 避免用 Promise.all 直接并发全部请求，改用分批 + await 或 async-pool 库
宏任务 + 微任务组合可实现精细调度
微任务会在每个宏任务结束后立即清空，这个特性可用于“让出主线程但保持逻辑连贯”。例如：
立即学习“Java免费学习笔记（深入）”；
- 批量更新 DOM 后，用 queueMicrotask(() => { /* 触发计算或校验 */ }) 确保在渲染前执行
- 在 setTimeout 回调里处理一批数据时，拆成小块，每块末尾用 queueMicrotask 推下一块，避免长时间阻塞
- 防止宏任务堆积导致卡顿：把非紧急任务延迟到下一个宏任务（setTimeout），紧急响应则走微任务
UI 渲染与宏任务的隐式协同
浏览器在每次宏任务执行完毕、微任务清空后，会检查是否需要渲染。这意味着：
- 连续修改 DOM 不会立刻重绘，直到当前宏任务结束
- 想强制看到中间状态（比如加载动画），得用 setTimeout 把后续逻辑推到下一个宏任务，给渲染留出机会
- requestAnimationFrame 是一种特殊宏任务，它在渲染前执行，适合做动画帧同步，但不参与普通宏任务排队逻辑
