聊一下活动倒计时的一些实践方案与思考。方案总体来说分为两种：
方案一：依赖本地时间
当然不能简单粗暴的直接获取本地时间来倒计时，结果可能是每个用户的倒计时时间千差万别，而且用户可以恶意更改本地时间去绕过倒计时操作。
方案：接口获取到服务前当前时间以后，与本地时间做一个差值计算。循环中使用本地时间加时间差得出当前时间，来计算倒计时时间，并在一定频率内更新服务器、本地时间差值。
// 接口获取服务器当前时间，并计算与本地时间的时间差
const timeDiff = serverTime - new Date().getTime()
setTimeout(() => {
// 当前时间 = 本地时间 + 时间差
const currTime = new Date().getTime() + timeDiff
// 倒计时时间 = 截止时间 - 当前时间
const countDown = endTime - currTime
// 显示倒计时信息
setCountDownInfo(countDown)
}, 1000)
优点：
-
js倒计时有延迟。如果单纯使用js的setTimeout倒计时，代码运行时间越长偏差越大，本地时间的准确性就很可以实时纠正js倒计时的偏差。 -
pc端浏览器进入后台运行，
js计时器会变慢；移动端应用进入后台运行，js计时器会直接停止，导致倒计时严重偏差。而依赖本地时间，就可以纠正这些偏差。
缺点：
用户也是可以修改本地时间绕过计时器的。需要一定的频率，获取服务器时间更新时间差值，防止用户修改本地时间。
方案二：js倒计时
方案：获取到服务器时间以后，js用
setTimeout做倒计时，不依赖本地时间。
// 接口获取服务器当前时间
let currTime = serverTime
setTimeout(() => {
// 当前时间 = 服务器时间 循环累加
currTime = currTime + 1000
// 倒计时时间 = 截止时间 - 当前时间
const countDown = endTime - currTime
// 显示倒计时信息
setCountDownInfo(countDown)
}, 1000)
优点：解决了依赖本地时间的弊端
缺点：前边提过，js定时器有偏差；页面后台运行，定时器会变慢。需要一定的频率，获取服务器当前时间矫正这些偏差
思考一：校准时间的频率
无论上述哪种方案，无论矫正js定时器偏差还是更新时间差值防止修改本地时间，频率的设定都很重要，可以根据场景区分
1. 倒计时的重要性：
- 直接控制秒杀或购买按钮的倒计时，准确性要求最高，所以需要频率相对高；
- 其次就是浮标、活动入口按钮、落地页等提示类倒计时，不涉及主要业务逻辑，准确性要求低，可以频率设定相对低；
2. 距离倒计时结束的时长
- 距离还很长时，更新频率高，没必要而且很浪费服务器资源。
- 倒计时马上结束时，更新频率很低，精度就会很差。
所以通常倒计时越接近结束时，准确性要求越高。可以根据倒计时时长，来动态设定更新频率，倒计时距离结束越近，更新的频率越高，并且设定频率最高阈值；反之同理。
比如倒计时为5分钟时，30s更新一次：(5 * 60 * 1000) / 30 = 当前时间差(ms) / 当前频率(s)，就可以获取动态的更新频率
3. 当然频率具体的数值，还要根据接口稳定性和用户数量决定
思考二： 使用setTimeout还是setInterval
试想：
- 如果
setInterval定时器间隔时间总是小于操作执行时间时，事件队列中就会排起队 ：本次循环事件未执行完，下次循环的事件已经添加进队列中 - 而且 当使用
setInterval时，仅当没有该定时器的任何其他代码实例时，才将定时器代码添加到队列中
所以：
- 丢帧： 那么下次循环结束时，因为队列中已经有它的一个实例，就不会向队列中添加事件了，所以这次事件执行就会丢失。
- 而且当前的事件执行完毕后，就会马上执行队列中已经添加的事件，这两次事件执行的时间间隔就会变小甚至无间隔
总结：
一定时间间隔重复做某些操作时，setInterval可能会出现丢帧和操作之间无时间间隔的情况。所以尽量使用setTimeout，它可以保证事件在相同时间间隔内执行，并且不丢失事件。
参考这篇文章
思考三： 为什么setTimeout时间间隔会有偏差
setTimeout只是负责准时的把事件添加进事件队列中，但是如果js线程在忙于执行其他任务 (处理用户交互、js代码执行等)，那么这个事件就需要等待线程空闲了才能被执行。
如果setTimeout递归实现倒计时，上述等待js线程产生的延迟就会在不停的循环中被叠加累计，延迟偏差就会越来越大，计时就会越来越不准。
