在商城项目中「倒计时活动」几乎是绕不开的需求秒杀、限时优惠、拼团、支付剩余时间……我相信很多都跟我一样一开始写出类似这样的代码/* by 01022.hk - online tools website : 01022.hk/zh/ascii.html */ setInterval(() { remainTime-- }, 1000)功能能跑但线上问题也会跟着跑出来。一、为什么 setTimeout / setInterval 不适合活动倒计时它们天生就不准很多人对定时器有一个误解setInterval(fn, 1000)≠ 每 1000ms 准时执行原因只有一个JavaScript 是单线程的。到这你先回想一下事件循环机制有哪些然后再往下看如果实在想不起来就先上网搜下或者看看我的单线程原理。事件循环机制主线程被渲染卡住执行大量 JSGC、布局、重绘都会导致定时器回调被延后执行。倒计时的表现就是跳秒变慢和真实时间对不上浏览器会「故意」降级定时器这是活动倒计时最容易翻车的一点。当页面进入以下状态后台 Tab页面最小化手机锁屏浏览器会主动做这些事延长定时器触发间隔甚至直接暂停执行结果就是用户切个 Tab 回来倒计时还显示 10 秒实际活动已经结束。对活动类业务这是不能接受的。setTimeout 递归本质问题没变可能有的会写成这样/* by 01022.hk - online tools website : 01022.hk/zh/ascii.html */ function tick() { setTimeout(() { remainTime-- tick() }, 1000) }看起来比setInterval稳一点但实际上依然受线程影响依然受浏览器限流依然不可靠只是“写法高级了”问题没解决。二、倒计时的核心思路必须反过来错误思路很多第一版代码“我现在有 60 秒每秒减 1”正确思路真实业务“活动有一个确定的结束时间点我只计算当前时间与结束时间的差值”正确的倒计时模型后端返回活动结束时间戳endTime前端永远不存“剩余秒数”每次渲染时const remain endTime - Date.now()前提是Date.now()是可信的这样做的好处是页面卡顿不影响切 Tab 不影响页面刷新不影响时间一定是真实世界的时间三、requestAnimationFrame 在倒计时里的正确用法那么有的就得来犟一下那是不是可以用 requestAnimationFramenonono是这样的requestAnimationFrame 适合“展示型倒计时”不适合直接当计时器。为什么 rAF 比 setInterval 好一点跟随浏览器刷新节奏通常 60fps页面不可见时自动暂停省性能不会出现多个定时器竞争但它的问题也很明显后台直接停不保证时间间隔本质还是“帧驱动”不是“时间驱动”正确用法rAF 时间戳差值function startCountdown(endTime, update) { function loop() { const remain endTime - Date.now() if (remain 0) { update(0) return } update(remain) requestAnimationFrame(loop) } loop() }rAF 只负责触发更新时间完全由Date.now()决定不用 rAF 去「数秒」这种方式非常适合大屏倒计时动画数字变化强 UI 表现的倒计时四、真实业务里的性能坑多个倒计时 多个定时器列表页如果有 20 个活动20 个setInterval页面性能直线下降组件卸载忘记清理内存泄漏幽灵定时器难以排查的线上问题前后端时间不同步前端显示没结束后端接口已判定结束用户点击直接报错五、重点来了第三方方案怎么选dayjs / date-fns强烈推荐它们不是倒计时库但非常适合做倒计时。示例dayjsimport dayjs from dayjs const endTime dayjs(2026-01-30 20:00:00) setInterval(() { const diff endTime.diff(dayjs(), second) console.log(diff 0 ? diff : 0) }, 1000)时间计算可靠不依赖定时器精度和后端时间模型一致这是我线上最常用的方案之一。自己封装一个「全局时间驱动器」这是很多成熟项目最终都会走到的一步。核心思想全局只存在一个 timer / rAF所有倒计时组件订阅它统一调度、统一销毁简单示意const listeners new Set() setInterval(() { const now Date.now() listeners.forEach(fn fn(now)) }, 1000) export function subscribe(fn) { listeners.add(fn) return () listeners.delete(fn) }组件只关心subscribe(now { remain.value endTime - now })性能稳定行为一致易维护UI 倒计时组件慎用很多组件库提供Countdown /Timer /适合展示Demo非关键业务不适合活动判定支付风控相关逻辑展示可以用业务别依赖。六、SO倒计时不是在“数秒”而是点对点的时间差。setTimeout / setInterval只能当“触发器”requestAnimationFrame只负责“渲染节奏”真正的时间永远来自时间戳差值如果一个倒计时切 Tab 就不准刷新就重置和后端状态对不上那它大概率不是 UI 问题而是时间模型错了。再记住三个原则前端时间永远不能当权威用「服务端时间差」而不是本地时间服务端多分布只允许一个地方定义关键状态以接口返回为准为什么说这三个大家可以好好思考下评论区欢迎大家讨论