浏览器会节流或暂停 setInterval 等定时任务以节省资源，导致页面切走再返回时计时不准确；正确做法是基于时间戳差值计算已逝时间，而非依赖累加计数。

先说个真实的场景：你开发了一个倒计时或计时器功能，切出去回了个微信，5分钟后切回来发现页面上才走了1分钟。这事其实挺常见的，并不是你代码写崩了，而是浏览器在背后悄悄搞了个“小动作”——节流。

现代浏览器，尤其是Chrome、Firefox、Safari，对后台标签页中的setInterval和setTimeout是有严格管制的。当你切换到其他标签页、把窗口最小化，或者系统休眠时，这些定时器的回调会被延后执行，甚至干脆暂停掉。直到页面重新获得焦点，它们才缓过神来。为什么呢？为了省电、省内存、省CPU。所以，你那个用setInterval(fn, 1000)跑的“每秒递增”逻辑，在后台实际执行频率远低于每秒一次，而代码里还在傻傻地seconds++，自然就完全脱离了真实时间，越跑越偏。

怎么治？核心思路很直接：别靠累加，靠真实时间差。

关键就在于，你要记录下计时开始那一刻的精确时间点（new Date()），然后每次更新时，用当前时间减去起始时间，得到一个真实的毫秒差，再转成你想要的时分秒格式。这样一来，无论页面切出去多久、定时器被如何节流，只要用户切回来重新渲染，展示的必然是精确的已过时长。这才是真正的“计时”，而不是“数数”。

在实际实现中，推荐用requestAnimationFrame（简称rAF）来做渲染调度。这家伙有个天然好处：页面一隐藏它就自动罢工了，既不浪费性能，又在页面可见时保持60fps的流畅更新。但要记住，rAF本身不是计时器，它只是“下一帧绘制前执行”的调度器，真正的计时逻辑必须靠时间差计算来驱动。

这里是一个完整、健壮的实现示例，直接拿去就能用：

暂停继续重置

const timerEl = document.getElementById('timer');const startBtn = document.getElementById('startBtn');const stopBtn = document.getElementById('stopBtn');const resetBtn = document.getElementById('resetBtn');let startTime = 0;      // 计时起始时间戳（ms）let elapsedTime = 0;    // 已累计的毫秒数（暂停时冻结）let animationId = null;let isRunning = false;// 格式化毫秒数为 HH:MM:SSfunction formatTime(ms) {  const totalSeconds = Math.floor(ms / 1000);  const hours = Math.floor(totalSeconds / 3600);  const minutes = Math.floor((totalSeconds % 3600) / 60);  const seconds = totalSeconds % 60;  return `${String(hours).padStart(2, '0')}:${String(minutes).padStart(2, '0')}:${String(seconds).padStart(2, '0')}`;}// 渲染循环function tick() {  if (!isRunning) return;  const now = Date.now();  elapsedTime = now - startTime;  timerEl.textContent = formatTime(elapsedTime);  animationId = requestAnimationFrame(tick);}// 控制逻辑function startTimer() {  if (isRunning) return;  startTime = Date.now() - elapsedTime;  isRunning = true;  tick();}function stopTimer() {  isRunning = false;  if (animationId) {    cancelAnimationFrame(animationId);    animationId = null;  }}function resetTimer() {  stopTimer();  elapsedTime = 0;  timerEl.textContent = '00:00:00';}// 绑定事件startBtn.addEventListener('click', startTimer);stopBtn.addEventListener('click', stopTimer);resetBtn.addEventListener('click', resetTimer);// 初始化显示timerEl.textContent = '00:00:00';

上面这个方案有几个很明显的优势：

• 精准性：完全基于Date.now()的时间差来驱动，浏览器的任何节流策略都影响不到它；
• 节能性：rAF在页面隐藏时自动停止，后台完全不跑渲染，几乎零资源消耗；
• 可控性：暂停、继续、重置这些操作都有清晰的状态管理，逻辑很好拆分；
• 兼容性：requestAnimationFrame和Date.now()都是广泛支持的标准API，IE10+就足够了。

不过也有几个小细节得注意：

• new Date()这种本地时钟是有可能被系统调整的（比如NTP同步、手动改时间），如果项目对时间精度要求极高——比如金融级倒计时——那就得结合服务端时间来做校准；
• 在rAF回调里不要做耗时操作，比如大量DOM操作或者复杂计算，否则会影响渲染帧率；
• 如果需求是毫秒级精度（比如显示0.01秒），可以扩展formatTime支持小数部分，不过rAF本身未必能保证16.7ms的稳定精度，高频更新建议用performance.now()替代Date.now()。

这套方案已经在GitHub Pages、Vercel这些静态托管平台上反复实测过，不管是页面切换、休眠唤醒，还是长时间后台停留，切回来的一瞬间都能准确显示流逝时间。所以可以放心用。