setTimeout 计时机制详解：系统时间变了，定时器为何不受影响？

这个问题在开发者社区里经常被问到，但很多人写了两三年 JavaScript 也不一定认真想过：setTimeout(fn, 1000) 里的 1000 到底是怎么被计算机计时的？它是看系统时间走到哪个点了，还是自己在后台默默数秒？如果我现在把系统时间往前调 20 分钟，正在排队等待的定时器会提前触发吗？如果电脑休眠 10 分钟再唤醒，定时器是立刻执行，还是把剩下的时间补完再执行？

我的经验答案是：setTimeout 作为定时器，它的底层机制通常不是去反复读取系统的墙上时钟（比如 Date.now()），而是使用系统提供的一个相对、单调递增的时间基准来估算“还要等多久”。所以，系统时钟被人为修改时，已经排队的 setTimeout 一般不会跟着“提前触发”或“无限延期”。但这不代表 setTimeout 就是严格的“经过时间”——因为事件循环阻塞、后台标签页节能策略、系统休眠、定时器嵌套节流等因素，都会让真实触发时间远远大于你设定的那个数。

这篇文章会把这层东西彻底拆开：什么是系统时钟和单调时钟、时间循环里 setTimeout 怎么被调度、系统休眠/改动时间后具体会发生什么，以及怎样设计代码才不会被这些时间陷阱坑到。不管你是写业务页面还是做基建，只要用过 setTimeout、setInterval、倒计时、动画节流，都值得花几分钟弄明白这些底层逻辑。

1. 秒表不是墙上时钟：setTimeout 的时间基准到底是什么

1.1 计算机里有两套完全不同的“时间”

要搞清楚这个问题，先要把两样东西分开：墙上时钟（wall clock）和单调时钟（monotonic clock）。

墙上时钟就是我们平时看的时间，从 1970 年 1 月 1 日 0 点 0 分 0 秒（UTC）开始算到现在经过了多少毫秒。在 JavaScript 里，最典型的就是 Date.now() 和 new Date()。这种时间的特征是“可以被用户、NTP 校时、时区设置随意改变”。比如你把系统时间从 12 点改成 1 点，Date.now() 的返回值会瞬间跳变 3600 万毫秒。

单调时钟就不一样了，它不关心现在到底是几点几分，它只记录“从某个基准时刻开始，系统持续运行了多久”。比如电脑开机后到现在运行了 5000 秒，那单调时钟就是 5000 秒。它不会因为你把系统时间从 12 点改成 1 点就跟着跳动，它就是一把只往前走、不回拨的尺子。C/C++ 里常见的 clock_gettime(CLOCK_MONOTONIC)、Go 里的 time.Now().Sub(start)、Node.js 里的 process.hrtime() 底层大多基于这种时间基准。

JavaScript 业务代码里能直接感知单调时钟的 API 是 performance.now()。它返回“从页面打开/导航开始时到当前时刻经过了多少毫秒”，而不是“当前是几点几分”。你随便什么时候调用它，它都只跟页面生命周期挂钩，不会受系统时间修改影响。

这两套时间系统在日常开发里常常混在一起，容易栽跟头。比如你要计算一段代码跑了多久，如果用 Date.now() 相减，万一执行中间有人把系统时间往前调了 5 分钟，计算结果直接变成负数。正确做法是用 performance.now()，因为它背后就是单调时钟。

1.2 setTimeout 用的是哪一套

setTimeout 内部关心的是“延迟等待多久”，而不是“现在几点”。所以它在设计上更接近单调时钟，而不是墙上时钟。

你可以在浏览器里做一个实验：先设置一个 5 秒后的 setTimeout，然后在系统设置里把时间往后调 1 小时，再等 5 秒。实验结果通常是，回调依然会在原来的 5 秒左右触发，不会因为你把系统时间调快了 1 小时就提前 1 小时触发。反过来，把系统时间往前调 1 小时，已经排队的定时器也不会因此推迟 1 小时。

用一个生活中的比喻来说：setTimeout(1000) 就像一个厨房定时器，你拧到 1 分钟的位置，它会根据内部的发条或电子计时电路倒计时 60 秒。它不是每次看一眼墙上时钟“哦，现在 12:01，所以我应该 12:02 响”。如果厨房定时器是依赖墙上时钟来判断的，那你半夜把钟从 1 点拨到 2 点，它可能立刻响了。真实的厨房定时器不会这样，setTimeout 在运行中的主流环境里也不会这样。

但这句话需要再严谨一点：setTimeout 不是直接暴露给 JS 引擎的 API。浏览器的定时器由渲染进程里的定时器管理模块负责，Node.js 的定时器则由 libuv 的事件循环来管理。各自的底层实现会用系统提供的相对时间或平台相关的高精度计时接口。虽然不同运行环境在细节上有差异，但它们都不是通过“等待时反复调用 Date.now() 判断到没到时间”这种方式实现的，因为那太脆弱了，系统时间一跳，所有定时器都会乱套。

1.3 为什么要刻意避开系统时钟

从工程角度看，定时器如果依赖墙上时钟，会遇到两个很大的问题。

第一个问题是系统时间可被任意修改。普通用户为了调时区、校准时间、甚至单纯想玩游戏，都可能动系统时间。服务器上还有 NTP 自动校时，随时有可能把时间往外拨或往前拨几百毫秒。如果定时器的到期时间全用 Date.now() + 1000 去算，系统时间一旦发生跳变，所有排队的定时器的触发顺序和触发时间都会被破坏。这在一个基础计时器组件里是无法容忍的。

第二个问题是墙上时钟不是单调的。世界上很多地区有夏令时，虽然中国已经取消很久了，但海外用户仍然会遇到一年两次“凭空多一小时/少一小时”的情况。时区切换、手动改时间，都会让墙上时钟出现重复或跳跃。而实现一个任务调度器时，最理想的情况是“给每个定时器记录一个绝对单调的到期时间，然后不停检查到期时间是否小于当前单调时间”。这样，不管墙上时钟怎么跳，调度器内部的排序仍然稳定。

所以，浏览器实现和 Node.js 实现都会优先选择一种“相对时间/单调时间”的机制。可以说，setTimeout 不是为了回答“现在几点”而存在的，它是为了回答“现在距离开始时刻过了多久”而存在的。

2. 事件循环里的 setTimeout：“至少 1000ms”是怎么被击穿的

既然知道了基准是相对时间，很多人会以为 setTimeout(fn, 1000) 就代表“1000ms 后绝对执行”。这句话只对了一半，准确说法是“最早 1000ms 后执行”。把后面那层“最早”忽略掉，是很多线上定时器 bug 的来源。

2.1 一个简单的阻塞实验

你可以把下面这段代码丢到浏览器控制台里跑一下：

javascript复制const start = performance.now();

setTimeout(() => {
  console.log('setTimeout 实际触发于:', performance.now() - start);
}, 1000);

// 模拟一个同步耗时任务，例如 1500ms
const blockEnd = performance.now() + 1500;
while (performance.now() < blockEnd) {
  // do nothing
}

这段代码的逻辑非常直白：在主线程上用同步循环阻塞 1500ms，然后看 setTimeout(1000) 是否还能按 1000ms 触发。结果你会发现，它打印出来的时间大约是 1500ms，而不是 1000ms。

原因是 JavaScript 的单线程事件循环模型决定了主线程一次只能干一件事。当主线程正在执行同步代码时，定时器就算到期了，它的回调也只会被放进任务队列里等待，不能打断当前正在执行的任务。只有在当前调用栈清空、事件循环去任务队列里取下一个任务时，定时器回调才有机会运行。

所以，setTimeout(1000) 的 1000ms 更准确的理解是：只要主线程有空，至少 1000ms 后执行；如果主线程正好在忙，那只能等忙完再说。它不是你在其它线程里设一个硬件中断，时间一到立刻把你的代码插进去。

2.2 宏任务与微任务的顺序陷阱

与 setTimeout 相关的还有一个容易忽略的规律：它是一个宏任务。

当你在一个 setTimeout 回调里继续嵌套 setTimeout，或者在 Promise 回调、MutationObserver、queueMicrotask 这些微任务里做了大量计算，都会影响后面的定时器触发。

举个典型场景：

javascript复制setTimeout(() => {
  console.log('first timeout');
}, 0);

Promise.resolve().then(() => {
  for (let i = 0; i < 1e9; i++) {
    // 模拟大量微任务或同步计算
  }
  console.log('microtask done');
});

这里 setTimeout(0) 虽然写的是延迟 0ms，但 Promise 微任务在当前宏任务结束前就会全部执行完。如果 Promise 里同步阻塞了很久，setTimeout(0) 也只能排在后面。这就是为什么很多人问“为什么我的 setTimeout(0) 没有立即执行”的原因——它不可能插队到微任务前面。

代码里如果想要让某件事“尽快做，但别阻塞当前渲染/交互”，可以考虑把任务拆成 setTimeout 宏任务，让它让位于当前任务的高优先级逻辑。但千万别把一个需要精确播放节奏的动画或者倒计时完全寄托在 setTimeout(0) 上，因为你根本不知道上一个微任务队列到底有多长。

2.3 嵌套定时器的 4ms 惩罚

除了主线程阻塞，setTimeout 还有个隐藏规则：如果定时器存在嵌套，并且嵌套深度超过 5 层，那么浏览器会强制把这个定时器的最小延迟提高到至少 4ms。

这里说的“嵌套”通常是这样：

javascript复制let count = 0;

function tick() {
  count++;
  setTimeout(tick, 0);
}

setTimeout(tick, 0);

这种写法表面上是“每隔 0ms 执行一次”，但因为每次都从回调里继续注册新定时器，嵌套深度会不断累积。为了避免开发者用这种写法把 CPU 烧光，浏览器会自动将第 5 层之后的 setTimeout(0) 当成至少 4ms 的延迟来处理。

所以，那种想用 setTimeout(0) 实现一个 60fps 循环的写法，实际跑起来可能不是 16.7ms 一次，而是有时候 0ms、有时候 4ms、有时候因为浏览器合并和节流变成十几毫秒。这种场景应该用 requestAnimationFrame 或者基于 performance.now() 计算下一帧间隔，而不是盲目依赖定时器。

2.4 后台标签页和节能模式时发生了什么

比 4ms 惩罚更狠的是浏览器对后台标签页的节流策略。

当你把页面切到后台，浏览器会认为这个页面不可见、不需要频繁更新 UI，于是会把定时器的触发频率大幅降低。历史上 Chrome 会把后台页面定时器的最小延迟提升到 1000ms，后来还演化出更复杂的节流策略。如果你在后台标签页里跑一个“每 5ms 统计一次时间”的定时器，实际结果可能是几百毫秒甚至一秒多才触发一次。

这里就出现了一个反直觉的现象：setTimeout 明明用的是单调时钟，按理说它应该按相对时间稳定推进，但由于浏览器策略、系统休眠、进程挂起这些外部因素，它最终的表现更像“经过时间会比预期长得多”。这不改变定时器的时间基准，只改变调度器的触发能力。

跟这个类似的是系统休眠。假设你设置了一个 10 分钟后执行的定时器，然后合上笔记本去吃饭，过了 30 分钟再打开。这时候定时器通常会立刻触发，因为对系统底层来说，睡着的这段时间虽然墙上时钟走了 30 分钟，但机器并没有实际运行，定时器机制要么被挂起、要么等唤醒后重新检查到期时间时发现已经远远超过预设值。从用户感知上看，“从设置到真正执行”大大超过了 10 分钟，但你没法说它是“按照墙上时钟等待了 30 分钟”，只能说是“中间系统没在跑，醒来后发现到期了，就执行了”。

3. 系统时间跳变与休眠场景：哪些变了，哪些没变

3.1 手动修改系统时间的实测结论

为了把这个问题讲得再具体一点，你可以在本机做一个这样的对比实验：

先执行一段代码，设置一个 10 秒后的定时器，并记录开始时的时间：

javascript复制const startWall = Date.now();
const startMono = performance.now();

setTimeout(() => {
  console.log('Date.now() 经过时间:', Date.now() - startWall);
  console.log('performance.now() 经过时间:', performance.now() - startMono);
}, 10000);

在定时器等待的这 10 秒里，手动把系统时间往后调 1 小时。注意观察控制台输出。

如果 setTimeout 依赖系统墙上时钟，那么 Date.now() - startWall 会变成大约 3600010 毫秒，因为系统时间跳了 1 小时。但实际常见的浏览器结果里，这段差值并不会因此变成 1 小时，因为 Date.now() 读取系统时间确实会跳变，但定时器依然会按自己的节奏在 10 秒左右触发。所以你会看到 Date.now() - startWall 可能是 3600xxx 毫秒，而 performance.now() - startMono 却稳定在 10000ms 左右。

有趣的是，这个实验也说明了一个关键点：如果你用 Date.now() 去测量一个 setTimeout 的触发耗时，系统时钟被改的时候，测量结果会变得非常诡异。这不是定时器本身错了，而是你的测量工具用错了。定时器内部用的是单调时间，但你拿墙上时钟去量它，自然量不准。

3.2 休眠唤醒后的“立即执行”

再看看休眠场景。多数操作系统在进入休眠时，CPU 会暂停运行，所有依赖 CPU tick 的定时器都被冻结。当系统唤醒后，内核会重新检查当前的单调时钟。如果你的 setTimeout 到期时间已经远远小于当前单调时间，那事件循环会把已经到期的定时器回调放到任务队列里，立刻执行。

这带来的影响是：你不能假设“定时器一定会等待完整剩余时间”。它更接近“当系统能够继续运行后，发现已经到期，就立即执行”。如果你用定时器去做一个“离开 10 分钟再回来触发”的提醒，效果上可能表现为“回来瞬间立刻提醒”，这通常符合预期。

但是，如果你用定时器去做精密的动画帧调度，或者在后台页面做网络轮询，那就必须考虑休眠和节流带来的时间跳跃。比如有些实时时钟页面会在系统唤醒后出现“秒针突然跳了一大格”，就是因为唤醒后积压的定时器被一次性补齐或者合并了。

3.3 系统休眠期间，performance.now() 也会“停住”吗

这里有个容易混淆的点。performance.now() 在大多数浏览器里被定义为单调时间，但它的单调性不等于“和墙上时钟永远没有误差”。在系统休眠期间，很多浏览器不会认为时间在流逝，所以休眠前后的 performance.now() 差值可能小于墙上时钟的差值。

简单说，performance.now() 更适合测量“程序实际运行期间经过的时间”，而不太适合测量“日历上从今天下午到明天下午经过的真实时间”。真正能让日历时间稳定推进的只有 Date.now() 或者服务端时间。所以在设计跨天提醒、定时发布、订阅到期等功能时，最终还是要回到墙上时钟，不能只用单调时钟算。

4. 不同业务场景：用“相对时间”还是“日历时间”

把前面的结论放到业务里，就引出了非常重要的设计思路：一段代码到底该用 setTimeout + 单调时间，还是用 Date.now() + 日历时间，取决于你要计算的是“持续时长”还是“日历时刻”。

4.1 适合用“持续时长”的场景

进度条动画、loading 展示、轮询间隔、令牌桶限流、代码性能测试，这些都属于“持续时长”类需求。它们关心的是“从这一刻开始，经过多少毫秒以后做下一件事”，不关心此刻究竟是上午十点还是下午三点。

这种场景最稳妥的做法是用 setTimeout 做延迟，再用 performance.now() 计算实际已经运行的时间。如果不依赖系统时间，即使 NTP 校时或用户改时区，也不会影响业务逻辑。

一个常见的错误是有人喜欢把“几秒后执行”写成：

javascript复制const executedAt = Date.now() + 5000;
while (Date.now() < executedAt) {
  // busy wait
}

这种同步忙等的方式不仅阻塞主线程，而且一旦系统时间被改，循环会立刻结束或无限延长。虽然没人会刻意这么写，但从原理上理解后你会发现，所有基于 Date.now() 的“时间差”计算都不能在时钟被跳变时保持稳定。

4.2 适合用“日历时间”的场景

闹钟提醒、日报统计、定时发布文章、判断“今天是否要展示引导弹窗”，这些都属于“日历时刻”类需求。它们关心的是“到了某个具体日期/时间点，执行某件事”，比如明天早上 8 点推送提醒。

对于这种需求，你应该先根据自己的业务基准时间（建议优先用服务端时间，避免完全依赖本地系统时间）计算出目标时刻减去当前时刻的差值，然后再把差值交给 setTimeout 去做相对等待。比如：

javascript复制const targetTime = new Date('2025-06-01T08:00:00').getTime();
const delay = Math.max(0, targetTime - Date.now());
setTimeout(() => {
  console.log('到点了');
}, delay);

这段代码的核心原理是：先把日历时刻转换成一个“相对等待毫秒数”，再交给 setTimeout。如果用户在这段等待期间修改了系统时间，setTimeout 本身不会跟着墙钟跳，但你在计算 delay 时用的 Date.now() 已经受影响了。所以，前期计算差值、等待过程中补偿、触发后再同步回系统时间，这三个环节都必须考虑时钟变化风险。

一个更健壮的做法是不要一次性把 setTimeout 设成几天几小时，而是每分钟醒一次检查剩余时间：

javascript复制function scheduleAt(targetTime, callback) {
  const timer = setInterval(() => {
    const remaining = targetTime - Date.now();
    if (remaining <= 0) {
      clearInterval(timer);
      callback();
    }
  }, 1000);
}

虽然这种写法看起来比较笨，但它能有效抵抗“长时间等待时系统休眠/时间跳变导致定时器不准”的问题。因为每个周期都会重新用 Date.now() 对齐一次目标日历时间。代价是稍微耗一点点电和定时器资源，但对大多数低频提醒场景来说完全值得。

4.3 用 performance.now() 做自校准的倒计时组件

如果你的需求是在页面上显示一个“距离活动结束还有 xx:xx:xx”的倒计时，而且活动结束时间是一个固定的服务端日期，那么比较标准的做法是混合两种时间源。

页面启动时先拿到服务端时间和本地时间的差值 offset，然后倒计时过程中完全用 performance.now() 驱动，避免本地用户改时间导致倒计时乱跳。每隔一段时间再向服务端发起一次时间同步，重新校准 offset。

javascript复制const serverTime = 1720000000000; // 假设从服务端拿到的时间戳
const localStart = performance.now();
const startWall = Date.now();
const offset = serverTime - startWall;

const endTime = serverTime + 7200000; // 活动结束时间
let timer;

function getCurrentServerTime() {
  // 当前预估服务端时间 = 真实本地单调经过时间 + offset + 启动时墙上时间差
  return startWall + (performance.now() - localStart) + offset;
}

function updateCountdown() {
  const remain = endTime - getCurrentServerTime();
  if (remain <= 0) {
    clearInterval(timer);
    return;
  }
  // 渲染剩余时间
}

timer = setInterval(updateCountdown, 1000);

你可能会觉得这个公式绕，但它的好处是稳：本地用户把系统时间从 1 点改到 3 点，页面上剩余时间不会突然减少两小时，因为倒计时的推进来自 performance.now() 这个单调时钟。只有服务端时间基准真的向前走，倒计时才会往前走。这在电商抢购、秒杀、竞拍等场景里非常关键。

5. 定时器实战中容易踩的坑

5.1 最大延迟时间溢出问题

很多人不知道 setTimeout 的延迟值是有上限的。在浏览器和 Node.js 环境中，当延迟时间大于 2147483647ms（约 24.8 天）时，很多实现会因为 32 位有符号整数的最大值限制而出现异常。有的环境会直接把它当作 0 处理，导致定时器“立刻触发”；有的环境会抛警告。

如果你要设置一个 30 天后的定时器，不能直接写：

javascript复制setTimeout(() => {}, 30 * 24 * 60 * 60 * 1000);

这已经超出约 25.9 天的上限。正确的做法是把长任务拆成很多段，每段不超过 24 天：

javascript复制const MAX_TIMEOUT = 2 ** 31 - 1;

function setLongTimeout(callback, delay) {
  if (delay <= MAX_TIMEOUT) {
    return setTimeout(callback, delay);
  }

  const timer = setTimeout(() => {
    timer = setLongTimeout(callback, delay - MAX_TIMEOUT);
  }, MAX_TIMEOUT);

  return timer;
}

这种拆段方式同样适用于系统休眠场景。因为拆成多段后，每一段开始都会重新注册剩余的延迟，能稍微降低一次性定时器在长期运行中被各种调度偏差影响的程度。

5.2 setTimeout 的第一个参数别传字符串

虽然 setTimeout('console.log(1)', 1000) 是老前辈们留下的历史写法，它会把字符串编译成新的函数执行，既慢又不安全。现在任何时候都只用函数作为第一个参数。

另外还要注意，函数传参时不能直接把“需要变量”的结果预先算好：

javascript复制let i = 0;
// 错误示例
for (var j = 0; j < 3; j++) {
  setTimeout(() => console.log(j), 100);
}
// 输出 3,3,3

这里需要用 let 或者闭包、Function.prototype.bind 来捕获每次循环的独立值。

5.3 记得清理定时器

在组件卸载、页面跳转、路由切换时，如果忘记清理 setTimeout，可能出现两类后果。

一类是内存泄漏：回调里引用了 DOM 元素或大型对象，定时器不清理，这些对象就一直被占着。另一类是逻辑错乱：一个异步操作已经没必要继续了，结果回调还是被触发了，导致你试图更新一个已经卸载的 DOM 节点，或者弹出一个不该出现的登录框。

正确做法是尽量把定时器句柄保存起来，在合适的生命周期里调用 clearTimeout。如果定时器很多，可以考虑用一个小工具函数统一注册和清理：

javascript复制const timeouts = new Set();

function registerTimeout(fn, delay) {
  const timer = setTimeout(() => {
    timeouts.delete(timer);
    fn();
  }, delay);
  timeouts.add(timer);
  return timer;
}

function clearAllTimeouts() {
  timeouts.forEach((timer) => clearTimeout(timer));
  timeouts.clear();
}

5.4 页面切换后旧定时器不会跟着新页面走

如果在浏览器的旧页面上设置了一个很长的 setTimeout，在超时之前用户刷新或跳转到新页面，旧的 JavaScript 上下文可能已经被销毁，定时器回调也就不会在新的页面里执行了。所以，如果想让一个任务跨页面保存，你应该把目标时间记录到 localStorage 或 sessionStorage 里，下次新页面加载时重新计算剩余时间，而不是期待旧页面的定时器活到下一个页面。

6. 常见问题排查与速查表

为了方便定位，我把日常开发中比较典型的现象整理成一个排查速查表，你可以直接对照查看：

关于 setInterval 的漂移问题，我再多说一句。setInterval 本身是按“每隔一段时间将回调加入任务队列”来设计的，如果回调里的计算耗时超过了间隔，那么回调会连续排队执行，中间可能没有真正意义上的停顿；如果回调耗时很短但每次执行时间不太固定，长期积累下来也会出现漂移。

如果需要保证“每隔多少毫秒执行一次，且不希望漂移越来越严重”，最简单的方式是用递归 setTimeout，并在每次触发后计算实际耗时来修正下一次的延迟。这种自校准方式比盲目依赖 setInterval 要稳定得多：

javascript复制const targetInterval = 1000;
let nextTick = performance.now();

function tick() {
  const now = performance.now();
  const drift = now - nextTick;
  nextTick += targetInterval;

  // 实际业务逻辑
  console.log('drift:', drift);

  setTimeout(tick, Math.max(0, targetInterval - drift));
}

setTimeout(tick, targetInterval);

这段代码每次计算出“理想中的下一次触发时间点”和“实际触发时间点”的误差，然后把误差从下一次延迟里扣掉。哪怕中途发生了一次 200ms 的阻塞，后续也会尽可能把节奏拉回正常轨道。

6.1 为什么服务端时间在定时器里总是被忽略

还有一类问题来自服务端渲染或者 Node.js 环境。很多前端页面里习惯性用 setTimeout 做延迟，但在 Node.js 服务端，setTimeout 的表现和浏览器有细微差别。Node.js 里你可以用 timer.unref() 让定时器不阻止进程退出，也可以用 timer.ref() 恢复对事件循环的引用。

如果要在服务端实现一个“每天凌晨 2 点清理日志”的任务，最好不要简单写一个 setTimeout 然后传一个 12 小时的延迟。更好的方式是启动时计算到第二天凌晨 2 点的毫秒数，用一个定时器等待，到点后再计算下一次时间。因为服务端可能因为部署、崩溃、休眠而错过定时器，完全依赖相对延迟太久很不靠谱。成熟的方案是使用 node-cron、BullMQ 定时任务或者系统级 cron 来管理，而不是真的把 setTimeout 挂几个月。

6.2 setTimeout 与 requestAnimationFrame 的分工

有些开发者会问：既然 setTimeout 可以控制延迟，为什么做动画还要用 requestAnimationFrame？原因很简单，因为 requestAnimationFrame 和浏览器渲染帧对齐。浏览器准备把新的一帧画到屏幕上的时候才会调用你的回调，帧与帧之间的间隔由屏幕刷新率决定，通常是 60Hz 下每 16.7ms 一帧，在 120Hz 设备上会更短。

用 setTimeout 做动画，回调可能在一个帧的中间或者两帧之间执行，结果你更新了 DOM，但浏览器还没到渲染时机，展示出来的效果可能不够平滑。而且 setTimeout 在后台标签页会被节流，导致动画明显卡顿。所以“动画帧用 requestAnimationFrame，普通延迟任务用 setTimeout”不是约定俗成，而是底层调度机制决定的必然分工。

requestAnimationFrame 的时间戳参数是基于单调时间和页面帧率对齐的，非常适合做“从上一帧到现在经过了多少毫秒”的计算。它不会像 setTimeout 那样被 4ms 嵌套惩罚和后台标签页节流搞得很惨。

6.3 Web Worker 里的定时器算是一个逃生通道吗

如果你需要在页面切到后台之后继续较精确地计时，可以考虑把计时放进 Web Worker。Web Worker 是一个独立线程，它拥有自己的 JavaScript 运行环境和事件循环，不直接受到主页面渲染阻塞的影响。浏览器对后台页面的定时器节流策略，通常也不像对主线程定时器那样严格。

但要注意，Web Worker 里没有 DOM，也没有 window 对象，但仍然有 setTimeout、setInterval、performance.now()。你可以让 Worker 持续计算时间，再通过 postMessage 把时间同步回主页面。这个方案特别适合“页面切到后台后，音乐播放进度条还要继续走”这类需求。

当然，如果浏览器整个进程都被系统挂起，比如电脑休眠或者浏览器进入冻结状态，Worker 里的定时器同样会暂停。没有哪个前端 JavaScript API 能真正意义上“在电脑关机后继续运行”。所以，如果你的业务要求“绝对准确”，最终底线一定是服务端定时任务，而不是前端定时器。

最后，我从这么多年的前端实践里提炼出一条判断准则：看到“多少毫秒后执行”“每隔多久执行一次”这种相对时间需求，优先用 setTimeout/setInterval + performance.now()，但永远假设它可能被主线程和系统策略耽搁；看到“到这个日期时间执行”“明早 8 点提醒”这种日历时刻需求，最终判断必须回到 Date 或服务端时间，并且在等待过程中要定期用系统时间重新对齐目标。你不需要把浏览器的定时器源码全读一遍，只要记住这个区分，就能避开绝大多数时间陷阱。