微任务队列由JavaScript引擎内部维护，无法手动管理，仅能通过Promise.then()、MutationObserver和queueMicrotask()等机制调度任务；queueMicrotask()比Promise.resolve().then()更轻量且语义明确，用于在当前同步代码结束后、下一个宏任务前执行回调。
微任务队列不是靠手动“管理”的
JavaScript 中没有 microtaskQueue.push() 或 getMicrotaskQueue() 这类 API。微任务队列由引擎内部维护，你只能通过特定语言机制“调度”任务进入它，无法读取、清空、暂停或优先级排序。
能触发微任务的只有几种明确方式：
-
Promise.resolve().then(...)和catch()/finally()回调 -
MutationObserver的回调（DOM 变更响应） -
queueMicrotask()—— 明确用于插入一个微任务的函数（ES2020+）
注意：setTimeout、setInterval、requestAnimationFrame 都不进微任务队列，它们属于宏任务（macrotask）。
用 queueMicrotask() 替代 Promise.resolve().then()
过去常写 Promise.resolve().then(fn) 来“尽快执行”，但这是种 hack：创建 Promise 实例有开销，且语义不清。现在应直接用 queueMicrotask()。
立即学习“Java免费学习笔记（深入）”；
queueMicrotask(() => {
console.log('这会在当前同步代码结束后、下一个宏任务前执行');
});
console.log('同步代码');
// 输出顺序：
// 同步代码
// 这会在当前同步代码结束后、下一个宏任务前执行
关键点：
-
queueMicrotask()接收一个函数，不返回任何值（无Promise返回） - 它比
Promise.then()更轻量，无状态、无链式能力，纯调度用途 - 在 Node.js 11+ 和现代浏览器中可用；旧环境需 polyfill（基于
Promise回退）
微任务与宏任务嵌套时的实际执行顺序
容易误以为“所有微任务都跑完才执行下一个宏任务”就等于“绝对线性”。但微任务里再调度微任务，会追加到同一轮微任务队列末尾，仍属本轮 —— 不会跳到下一轮事件循环。
console.log(1);
queueMicrotask(() => {
console.log(2);
queueMicrotask(() => console.log(3));
});
console.log(4);
// 输出：1 → 4 → 2 → 3
而如果在微任务里触发宏任务：
console.log(1);
queueMicrotask(() => {
console.log(2);
setTimeout(() => console.log(3), 0); // 这个 3 是宏任务，排到下一轮
});
console.log(4);
// 输出：1 → 4 → 2 → 3（但 3 在下一次事件循环才执行）
常见踩坑：
- 在
Promise.then()里递归调用自身，可能造成微任务无限膨胀，阻塞 UI 或触发栈溢出（虽无调用栈，但队列过长会卡死） - 误用
await Promise.resolve()做“让出控制权”，其实它只是插入一个微任务，并未真正交还给事件循环（不像await setTimeout(..., 0)）
为什么不能用微任务模拟“sleep”或“节流”
有人尝试用 await new Promise(r => queueMicrotask(r)) 模拟异步等待，但这不会让出线程，也不释放控制权给其他宏任务（比如用户点击、滚动），反而可能饿死其他任务。
真正需要延迟或节流时：
- 视觉更新/重排相关：用
requestAnimationFrame - 确保跨帧执行、避免阻塞渲染：用
setTimeout(..., 0)或postMessage（后者可触发微任务，但更可靠） - 精确时间控制：只能用
setTimeout/setInterval，微任务不接受延迟参数
微任务的本质是“当前操作原子性的延续”，不是“异步工具箱”。把它当队列来“管理”，本身就是方向错误。
