倒计时网页代码

去年双十一，倒计我蹲在电脑前抢一张显卡。时网页面左上角有个数字一直在跳：02:47、页代02:46、倒计02:45……每跳一下，时网我心跳就快一拍。页代结果到00:03的倒计时候，按钮亮了，时网我点下去——售罄。页代后来我才知道，倒计那个倒计时根本不是时网从服务器同步的，而是页代写死在页面里的一个JavaScript变量。刷新一下，倒计它又从头开始。时网

这事让我对倒计时网页产生了兴趣。页代你看到的那些跳动的数字，背后到底是怎么跑起来的？

最朴素的写法：一个setInterval就够了

假设你要做一个“距离元旦还有多久”的页面。核心逻辑就三步：定一个目标时间，拿当前时间减去它，把差值换算成天、时、分、秒塞进HTML里。用setInterval每1000毫秒跑一次这个计算，数字就会动了。

const target = new Date('2025-01-01T00:00:00'); setInterval(() => {  const now = new Date(); const diff = target - now; const d = Math.floor(diff / 86400000); const h = Math.floor(diff % 86400000 / 3600000); // ... 写入DOM }, 1000);

但这里有个坑：setInterval并不精确。浏览器忙的时候，回调可能延迟几十毫秒甚至更多。跑上几个小时，累积误差能到好几秒。对于“抢购”这种场景，几秒就是生死线。

更靠谱的做法：用requestAnimationFrame自己算时间

我后来改用了requestAnimationFrame。它跟着屏幕刷新率走，大概每秒60次。每次回调里不依赖“上一次的时间”，而是直接读Date.now()，用目标时间减去当前真实时间。这样即使某一帧延迟了，下一帧会自动修正，不会累积误差。

代价是计算频率高了。不过倒计时的运算量极小，这点开销可以忽略。真正要注意的是：别在每一帧里都去操作DOM。数字没变的时候，不更新。加个判断，只有秒数变化了才写入页面。

那些“假倒计时”是怎么做的

很多电商页面用的倒计时，其实是个固定时长的循环。比如“限时抢购，剩余02:00:00”，你刷新页面，它又从02:00:00开始。实现方式简单到离谱：页面加载时记录一个起始时间，然后用Date.now() - startTime去算已经过去了多久，再用总时长减去它。

这种倒计时的目的不是告诉你“真实还剩多少时间”，而是制造紧迫感。你知道它是假的，但它就是有用。我盯着那个数字从02:00跳到01:59的时候，手指确实会不自觉地往下滑。

时区、夏令时、服务器时间——三个容易翻车的地方

用new Date('2025-01-01')这种写法，浏览器会按本地时区解析。如果你的用户分布在多个时区，同一个倒计时在不同人屏幕上剩下的时间可能不一样。解决办法是统一用UTC时间戳，或者从服务器拉一个serverTime，再计算服务器时间和本地时间的偏移量，后续都用这个偏移量来校正。

夏令时更麻烦。某些地区每年切换两次，那一小时里倒计时可能突然跳变。如果你的目标时间跨越了夏令时切换点，最好直接用时间戳做减法，别去碰getHours()这类方法。

还有一个细节：用户电脑的时间是可以手动改的。把系统时间往后调一天，倒计时直接归零。所以严肃的场景必须用服务器时间做基准，前端只负责显示。

一个完整的倒计时需要处理什么

页面切到后台时，浏览器会降频requestAnimationFrame甚至暂停。用户切回来，数字可能停在几分钟前。解决办法是监听visibilitychange事件，页面重新可见时立刻强制刷新一次。另外，倒计时归零后要做什么？是隐藏数字、显示“已结束”，还是触发某个回调？这些边界情况不处理，上线后就是bug。

我现在的习惯是：任何倒计时组件，先写一个getRemaining()纯函数，输入目标时间和当前时间，输出剩余的天时分秒。UI层只负责把这个结果渲染出来。逻辑和展示分开，测试也好写。

回到开头那张显卡。后来我写了个脚本，每500毫秒请求一次库存接口，比页面倒计时靠谱多了。但那是另一个故事了。

很赞哦!（37）