在商城项目中，「倒计时活动」几乎是绕不开的需求：
秒杀、限时优惠、拼团、支付剩余时间……
我相信很多都跟我一样一开始写出类似这样的代码：
/* by 01022.hk - online tools website : 01022.hk/zh/ascii.html */ setInterval(() => { remainTime-- }, 1000)功能能跑，但线上问题也会跟着跑出来。
一、为什么 setTimeout / setInterval 不适合活动倒计时？
它们天生就不准
很多人对定时器有一个误解：
setInterval(fn, 1000)≠ 每 1000ms 准时执行
原因只有一个：
JavaScript 是单线程的。
到这你先回想一下事件循环机制，有哪些？然后再往下看；如果实在想不起来就先上网搜下，或者看看我的单线程原理。
- 事件循环机制
- 主线程被渲染卡住
- 执行大量 JS
- GC、布局、重绘
都会导致定时器回调被延后执行。
倒计时的表现就是：
- 跳秒
- 变慢
- 和真实时间对不上
浏览器会「故意」降级定时器
这是活动倒计时最容易翻车的一点。
当页面进入以下状态：
- 后台 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 在倒计时里的正确用法
那么有的就得来犟一下：
那是不是可以用 requestAnimationFrame？
nonono，是这样的
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（强烈推荐）
它们不是倒计时库，但非常适合做倒计时。
示例（dayjs）：
import 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 问题，而是时间模型错了。
再记住三个原则：
- 前端时间永远不能当权威
- 用「服务端时间差」而不是本地时间（服务端多分布只允许一个地方定义）
- 关键状态以接口返回为准
为什么说这三个，大家可以好好思考下，评论区欢迎大家讨论！
