JavaScript事件循环是单线程、基于队列的执行协调机制；宏任务（如setTimeout）执行后立即清空本轮所有微任务（如Promise.then），再取下一个宏任务，故Promise.then总先于setTimeout执行。
JavaScript 事件循环不是“调度器”或“多线程引擎”，它就是一个单线程的、基于队列的执行协调机制——所有异步回调（setTimeout、Promise.then、fetch 回调等）都靠它排队执行。
宏任务和微任务队列怎么分？
事件循环每次只从一个宏任务开始（如脚本初始化、setTimeout 回调、setInterval 回调、I/O 回调），执行完后，**立刻清空当前轮次的所有微任务队列**（Promise.then/catch/finally、MutationObserver、queueMicrotask），再取下一个宏任务。
常见误解：以为 Promise.then 和 setTimeout 是“同时排队”的——其实它们根本不在同一个队列里。
-
setTimeout(() => console.log(1), 0)→ 进宏任务队列（下一轮） -
Promise.resolve().then(() => console.log(2))→ 进微任务队列（本轮末尾立刻执行） - 输出顺序一定是
2、1，哪怕 timeout 设为 0
Promise.then 为什么总比 setTimeout 先执行？
因为 Promise.then 注册的是微任务，而 setTimeout 是宏任务。事件循环规则强制：每执行一个宏任务，必须把当轮微任务队列跑空，才允许取下一个宏任务。
立即学习“Java免费学习笔记（深入）”；
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
这意味着：
- 哪怕你写
setTimeout(() => {}, 0)，它也得等当前同步代码 + 所有已排队微任务全部执行完才能轮到 -
Promise.resolve().then(() => Promise.resolve().then(...))可以无限嵌套微任务，会阻塞下一个宏任务，甚至导致界面卡顿 -
queueMicrotask和Promise.then行为一致，但更轻量、无状态，适合简单调度
Node.js 的 process.nextTick 比微任务还快？
是的，在 Node.js 中，process.nextTick 的回调会在**当前操作结束后、任何微任务之前**执行——它优先级高于 Promise.then。这是 Node.js 特有的，浏览器不支持。
实际影响：
- 在 Node.js 中：
process.nextTick→Promise.then→setTimeout - 滥用
process.nextTick会导致事件循环无法进入下一宏任务，I/O 被饿死 - 不要用它替代
Promise.then做常规异步流程控制；它更适合底层库做错误冒泡或状态同步
真正容易被忽略的点：事件循环本身不“执行”异步操作（比如网络请求、文件读取），它只负责调度回调。真正的异步工作由宿主环境（浏览器或 Node.js 的 libuv）完成，并在完成后把回调推入对应队列——理解这个分工，才能不把“异步”全归给 JS 引擎。
