setTimeout(fn,0)与setTimeout(fn,1)的执行差异及原因探究

核心原因拆解 #

你的问题本质是Chrome浏览器对setTimeout的调度逻辑，以及主线程阻塞后的微任务/宏任务优先级调整导致的。

1. setTimeout(0)的特殊调度逻辑 #

浏览器规范里，setTimeout的最小延迟并非真的0ms，早期是4ms，现在Chrome在非嵌套调用场景下可低至1ms，但还有一个关键规则：当主线程被长时间阻塞（比如你的忙等待循环）后，setTimeout(0)的回调会被标记为「已过期任务」。

当忙等待结束，主线程刚恢复空闲时，Chrome的调度器会优先处理这类已过期的宏任务，跳过了常规的「宏任务执行完毕后先清空微任务队列」的流程——这是Chrome为了避免过期任务被无限延迟的调度优化，所以你会看到setTimeout回调先于fetch的微任务执行。

2. 1ms延迟后的正常执行逻辑 #

当你把延迟设为1ms时，setTimeout的回调执行时间会被明确设置为「调用时的当前时间+1ms」。你的忙等待循环阻塞了主线程（比如1秒），当忙等待结束后，这个1ms的延迟早已超过，但Chrome会把该回调放入常规宏任务队列，严格遵循Event Loop规则：先清空当前宏任务结束后的微任务队列（执行fetch回调），再取出宏任务队列里的setTimeout回调执行，这就符合你预期的顺序了。

3. 并非忽略微任务优先级 #

不是Chrome忽略了微任务优先级，而是对长时间阻塞后的0ms setTimeout触发了特殊调度逻辑：这类过期任务会被直接插入到主线程的下一个执行槽，跳过微任务处理环节。而1ms延迟不会触发这个特殊逻辑，所以遵循常规的Event Loop执行顺序。

内容的提问来源于stack exchange，提问作者Mert Avıncan