一、chrome中setInterval&setTimeout执行时机

先看一段代码：

console.log(1)
setTimeout(()=>{
    console.log(2)
})
const i = setInterval(()=>{console.log(3)})
setTimeout(()=>{
    console.log(4)
    clearInterval(i)
})

此时输出1、2、4即第二个setTimeout的回调要比setInterval更先执行。

原因是在目前的 Chrome 里 setInterval 的最小延迟时间不是 0，而是 1，即便你写了 0，Chrome 也会改成 1，而 setTimeout 没有这个限制，所以 setTimeout 回调会先被推入任务队列且先执行，也就执行了 clearInterval，所以不会打印 3。

我们试一下：

console.log(1)
setTimeout(()=>{
    console.log(2)
})
const i = setInterval(()=>{console.log(3)})
setTimeout(()=>{
    console.log(4)
    clearInterval(i)
},0.9)

从代码上看，过了0.9ms之后会将该回调扔进任务队列并执行，此时输出1、2、4
我们将其改为 1

console.log(1)
setTimeout(()=>{
    console.log(2)
})
const i = setInterval(()=>{console.log(3)})
setTimeout(()=>{
    console.log(4)
    clearInterval(i)
},1)

由于上面说了setInterval默认也是1，那么就会按照代码书写的顺序优先将setInterval推进队列，此时输出为 1、2、3、4
看chrome源码 其实setTimeout和setInterval都是在这一个函数里实现的，他俩通过single_shot区分，可以看到确实给setInterval的delay设定最小1ms

....
  // Clamping up to 1ms for historical reasons crbug.com/402694.
  // Removing clamp for single_shot behind a feature flag.
  if (!single_shot || !blink::features::IsSetTimeoutWithoutClampEnabled())
    timeout = std::max(timeout, base::Milliseconds(1));

  if (single_shot)
    StartOneShot(timeout, FROM_HERE);
  else
    StartRepeating(timeout, FROM_HERE);
  const char* name = single_shot ? "setTimeout" : "setInterval";
.....

结论：setInterval最小延迟是1ms，而setTimeout则是0ms

二、setTimeout在chrome中delay小于1ms时

  setTimeout(()=>{console.log(5)},5)
  setTimeout(()=>{console.log(4)},4)
  setTimeout(()=>{console.log(3)},3)
  setTimeout(()=>{console.log(2)},2)
  setTimeout(()=>{console.log(0)},0)
  setTimeout(()=>{console.log(1)},1)

输出：0、1、2、3、4、5 看其实是按照时间，没啥毛病
但是：

setTimeout(()=>{console.log(5)},5)
setTimeout(()=>{console.log(4)},0.4)
setTimeout(()=>{console.log(3)},0.3)
setTimeout(()=>{console.log(2)},2)
setTimeout(()=>{console.log(1)},1)
setTimeout(()=>{console.log(0)},0)

此时输出：4、3、0、1、2、5 （如果是safari输出 4、3、1、0、2、5）

说明当setTimeout的delay设置小于1ms时，不再根据等待时间将回调放入任务队列，这是咋回事呢？

在mdn文档中针对setTimeout的delay参数描述如下：

If this parameter is omitted, a value of 0 is used, meaning execute "immediately", or more accurately, the next event cycle.

如果是0的话就会被“立即”执行，更准确的讲是在下次时间循环时；但是上面例子中写的 0.3 ，0.4并不是0啊，为啥没有按照常规操作不根据delay来执行呢？

我们看一下chrome这部分源码 chromium源码

//https://github.com/chromium/chromium/blob/main/base/token.h#L48
....
constexpr bool is_zero() const { return words_[0] == 0 && words_[1] == 0; }
....
//https://github.com/chromium/chromium/blob/100.0.4845.0/third_party/blink/renderer/core/frame/dom_timer.cc#L99
...
 // Select TaskType based on nesting level.
  TaskType task_type;
  if (timeout.is_zero()) {
    task_type = TaskType::kJavascriptTimerImmediate;
    DCHECK_LT(nesting_level_, kMaxTimerNestingLevel);
  } else if (nesting_level_ >= kMaxTimerNestingLevel) {
    task_type = TaskType::kJavascriptTimerDelayedHighNesting;
  } else {
    task_type = TaskType::kJavascriptTimerDelayedLowNesting;
  }
...

可以看到内部会判断delay如果是 0 开头的delay的TaskType都会被定义为kJavascriptTimerImmediate。kJavascriptTimerImmediate又是啥呢？，我们可以看task_type.h这个文件，这里面记录了各个任务的优先级

...
  // https://html.spec.whatwg.org/multipage/webappapis.html#timers
  // For tasks queued by setTimeout() or setInterval().
  //
  // Task nesting level is < 5 and timeout is zero. 
  kJavascriptTimerImmediate = 72,
  // Task nesting level is < 5 and timeout is > 0.
  kJavascriptTimerDelayedLowNesting = 73,
  // Task nesting level is >= 5.
  kJavascriptTimerDelayedHighNesting = 10,
...

0.4ms、0.3ms是kJavascriptTimerImmediate类型任务，优先级是72；而其他 3ms 5ms等类型是kJavascriptTimerDelayedLowNesting优先级是73，这就是没有按照想象中的顺序执行的原因！

还有另外一个例子(chrome下)：

例子1：
setTimeout(()=> console.log('111'),1000)
alert('aaa')
setTimeout(()=> console.log('333'), 1)    //输出 111，333
例子2：
setTimeout(()=> console.log('111'),1000)
alert('aaa')
setTimeout(()=> console.log('222'), 0.9) 
setTimeout(()=> console.log('333'), 1)  
 //在chrome输出 222,111,333 而且可观察到alert弹出过了1000ms之后在点击‘确定’，输出111前没有1000ms延迟，说明在alert时计时器也在同时计数
// 但在safari是222,333,111  而且可观察到alert弹出过了1000ms之后在点击‘确定’，输出111前会有1000ms延迟，说明在alert时计时器并没有计时

例子1：原因是alert执行时我们的1000已经开始计时，点击alter的‘确定’使其消失的时间大于1000ms所以输出111,333。当我们把1000改为3000时，输出即为333，111

例子2：按照上面说的结论setTimeout的delay设置小于1ms时会被判断timeout.is_zero()为true及立即执行,就可以很好理解这个例子: 执行alert后就会将下面setTimeout(()=> console.log('333'), 0.9) 的回调直接放进任务队列中立即执行，即使此时经过了1ms第三个settimeout和经过1000ms第一个settimeout也已经推入到任务队列了，但是无奈被小于1ms的插队了；

结论：chrome小于1ms的行为和大于等于1ms时不一致，小于1ms时行为与0ms一致均‘立即’执行，但是safari无论是否小于1ms行为都一致；当delay均小于1ms时，chrome和safari均是按照代码书写顺序来执行，这点是一致的

另外及时设置了小于等于1ms实际的最小延迟时间也是4ms，所以真正执行回调时至少有4ms延迟。源码

...
constexpr base::TimeDelta kMinimumInterval = base::Milliseconds(4);
...
 if (nesting_level_ >= kMaxTimerNestingLevel && timeout < kMinimumInterval)
    timeout = kMinimumInterval;
...

三、 settimeout在node中delay小于1ms时

setTimeout(()=>{
    console.log(1)
},1)
setTimeout(()=>{
    console.log(0.2)
},0.2)   
//输出 1  0.2   而chrome中确是0.2  1

node中的源码在 lib/timers.js中

const {Timeout} = require('internal/timers');
function setTimeout(callback, after, arg1, arg2, arg3) {
  validateFunction(callback, 'callback');
  .....
  const timeout = new Timeout(callback, after, args, false, true);
  insert(timeout, timeout._idleTimeout);

  return timeout;
}

在看这个Timeout在 lib/internal/timers.js中, 可以看到最小值就是1ms

class Timeout {
  // Timer constructor function.
  // The entire prototype is defined in lib/timers.js
  constructor(callback, after, args, isRepeat, isRefed) {
    after *= 1; // Coalesce to number or NaN
    if (!(after >= 1 && after <= TIMEOUT_MAX)) {
      if (after > TIMEOUT_MAX) {
        process.emitWarning(`${after} does not fit into` +
                            ' a 32-bit signed integer.' +
                            '\nTimeout duration was set to 1.',
                            'TimeoutOverflowWarning');
      }
      after = 1; // Schedule on next tick, follows browser behavior
    }
    ...
    ...
}

结论：

1.代码层面chrome中setInterval最小延迟是1ms，而setTimeout则是0ms
2.chrome中settimeout中delay小于1ms时和预期行为不符，是因为源码中小于1ms被定义为与0ms一样的‘立即’执行任务了。还有个小点setTimeout的delay是向下取整的即1.9ms和1ms等价、0.8ms和0ms等价
3.node中settimeout的delay小于1ms时会被修改为1ms