为什么不推荐使用 setInterval

解释原因之前需要先简单介绍一下 js 的执行原理：js引擎是单线程的，主要分为主线程和事件队列，同步操作是在主线程上执行，而异步操作的函数会先放在事件队列当中，等到js主线程空闲了，才会去事件队列取出放到主线程执行。定时器是属于异步事件，参数里面设置的时间，并不是延迟多少秒去执行回调函数，这个时间代表的是延迟多少秒，把回调函数放到异步队列，等待主线程空闲再被执行。

如果按照上面的说法，假如同步代码耗时较长就会存在执行多次的问题，举个例子，假如设置一个 100ms 的定时器，定时器中代码需要执行1000ms，那么事件队列中就会添加10次定时器的函数（实际小于10次），这样1s之后会就执行10次代码，而不是我们想要的每隔 100ms 执行一次，对此js引擎解决方法是，当使用setInterval时，仅当没有该定时器的任何其他代码实例时，才将定时器代码添加到队列中。这确保了定时器代码加入到队列中的最小时间间隔为指定间隔。什么意思呢，看如下代码：

console.time('耗时')
var timer = setInterval(() => {
  for (let i = 0; i < 1100000000; i++) { // 900ms左右
  }
  console.log(0)
}, 100);

setTimeout(() => {
  console.log('1s了')
  clearInterval(timer)
  console.timeEnd('耗时') // 耗时: 1955.52490234375ms（打印结果不固定）
}, 1000);

看上去这里应该打印10个0才对，其实只会打印2个0，原因就是如果当事件队列当中，已经存在了定时器的回调函数，即使已经到了规定的间隔时间，也不会再把这个时间点的定时器回调函数放到事件队列当中，定时器依旧运行。当下一个约定时间又到了，如果事件队列当中依然存在定时器的回调函数，这个时间点的定时器回调函数也不会放进事件队列…

这样就会导致一些间隔被跳过了。如果需要每个定时器的回调函数都被执行到，这里就不能满足需求了。

还有一个常用的场景是使用 setInterval 进行ajax请求，如果某一次请求时间过长，就导致下一次甚至多次的请求被忽略掉，这显然是不能接受的。

递归setTimeout

为了避免setInterval()定时器的问题，可以使用递归setTimeout()

setTimeout(function fn(){
    setTimeout(fn,interval);
},interval);

这个模式递归调用了 setTimeout ，每次函数执行的时候都会创建一个新的定时器。第二个setTimeout()调用当前执行的函数，并为其设置另外一个定时器。这样做的好处是，在前一个定时器代码执行完之前，不会向队列插入新的定时器代码，确保不会有任何缺失的间隔。而且，它可以保证在下一次定时器代码执行之前，至少要等待指定的间隔，避免了连续的运行。因此 setTimeout 在某程度上比 setInterval 稳定。但无论是 setTimeout 还是 setInterval 都无法解决精准定时的问题。

参考：

https://blog.csdn.net/chiuwingyan/article/details/80322289