JavaScript异步回调：setTimeout延迟0秒为何晚于已resolve的Promise执行

你之前的理解误区，根源是把分属不同优先级的两类异步回调，都当成了同一个FIFO（先进先出）队列里的成员。

两类异步任务的队列分区 #

JS运行时的异步任务从来不是共用一个队列调度的，两类核心队列的优先级有明确高低：

• 宏任务队列：也就是你理解中存放普通回调的callback queue，专门接收setTimeout、setInterval、网络请求回调、I/O操作、UI渲染对应的任务。哪怕给setTimeout设延迟为0，它的回调也只会被归入这个队列。
• 微任务队列：专门接收Promise回调、queueMicrotask、MutationObserver对应的任务，优先级远高于宏任务队列。

事件循环的固定调度逻辑 #

每一轮事件循环的执行顺序是写死的，不存在不同队列的任务混排的情况：

1. 执行当前执行栈中所有同步代码，直到栈清空
2. 逐个执行微任务队列中所有任务，直到整个队列为空——哪怕执行微任务的过程中又新增了新的微任务，也会在本轮全部执行完，不会留到下一轮
3. 从宏任务队列中取出第一个符合FIFO顺序的任务执行
4. 跳回步骤2，再次清空微任务队列，进入下一轮循环

对应你给出的代码的实际执行流 #

1. 执行到setTimeout(() => console.log("hello"), 0)时：引擎会把这个回调交给定时器模块计时，哪怕延迟设为0，也要满足运行时要求的最小等待时间（通常为4ms，不同环境有差异）后，才会被放进宏任务队列，此时它根本没进入可被调度的执行序列
2. 执行到Promise.resolve('Success!').then(console.log)时：这个Promise的回调会被立刻放进微任务队列
3. 所有顶层同步代码执行完毕，执行栈清空
4. 按照调度规则先清空微任务队列：执行console.log('Success!')，输出第一行结果
5. 微任务队列清空后，才开始处理宏任务队列：这时等待时长达标的setTimeout回调被取出执行，输出hello

关键提醒：setTimeout(..., 0)的本质是“尽快把回调塞进宏任务队列”，但永远改变不了它的宏任务属性——当前轮次产生的所有微任务，优先级都比它高，这就是和你预期的FIFO顺序不一致的根本原因。

内容的提问来源于stack exchange，提问作者Logan Wlv