Firefox与Chrome下setTimeout回调执行顺序差异原因解析

首先明确所有JS环境共通的基础执行逻辑：

• JS为单线程事件循环模型，同步代码优先执行，阻塞阶段（比如代码里的while空转）只会注册定时器，不会执行任何定时器回调，必须等所有同步代码跑完才会开始调度宏任务队列。
• 这段测试代码里两段while循环累计阻塞400ms，等同步代码执行完成时，注册的4个定时器全部已经超过了设定的延迟时间，不存在未到期的情况。

差异核心：两个引擎的定时器队列实现逻辑不同 #

Firefox（SpiderMonkey引擎）逻辑 #

Firefox把所有setTimeout注册的定时器，统一存入一个按绝对到期时间戳从小到大排序的优先队列。事件循环每次取宏任务时，直接取队列中到期时间最早的任务执行，没有额外的优先级分层。
测试代码里4个定时器的理论到期时间分别为：

• 定时器1：run函数启动后0ms
• 定时器2：run函数启动后100ms
• 定时器3：run函数启动后200ms
• 定时器4：run函数启动后400ms
  按时间排序执行顺序就是1→2→3→4，和观测到的Firefox输出完全一致。

Chrome/Node.js（基于Chromium事件循环/libuv）逻辑 #

Chromium系环境没有用统一的时间优先队列，而是把定时器拆成两个独立队列存储，存在明确的优先级差异：

• 高优先级即时队列：存放延迟参数小于等于最小延迟阈值（前台页面非嵌套场景为1ms，嵌套调用场景为4ms）的定时器，测试代码里所有传0延迟的定时器1、3、4都在这个队列
• 普通延迟队列：存放延迟参数大于阈值的定时器，测试代码里延迟100ms的定时器2就在这个队列

调度规则为：

1. 默认优先从高优先级即时队列取任务执行
2. 内置饿死防护机制：不会无限制连续执行高优先级任务，每执行完1~2个高优先级任务（或累计高优先级任务执行时长超过1ms），就会检查普通延迟队列中是否存在逾期过久的任务，如果有就优先取出执行，避免长延迟任务被0延迟任务无限插队饿死。

对应测试代码的执行流程：

1. 同步代码跑完，先取高优先级队列第一个任务（定时器1）执行，输出1
2. 再取高优先级队列下一个任务（定时器3）执行，输出3
3. 此时触发饿死防护检查，发现普通延迟队列里的定时器2已经逾期300ms，符合优先调度条件，取出执行输出2
4. 回到高优先级队列取出剩余的定时器4执行，输出4
   最终结果就是观测到的1→3→2→4。

移除第一个0延迟定时器后结果一致的原因 #

删掉定时器1之后，高优先级队列里最早的任务是定时器3（到期时间200ms），普通延迟队列里的定时器2到期时间是100ms，比高优先级队列最早任务的到期时间更早。这时候Chrome不会触发高优先级队列的优先抢占逻辑，会直接按到期时间先后取任务，先执行2，再执行3、4，和Firefox的统一时间排序逻辑结果完全匹配，所以所有平台输出一致。

注：不同Chrome版本的饿死防护阈值、队列拆分细节可能有微调，但核心的分层队列+高优先级优先+饿死防护的逻辑是固定的，这也是这类跨环境定时器顺序差异的根本来源。

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