JS计时器三兄弟：setTimeout、setInterval、requestAnimationFrame详解与实战

1. 计时事件不止 setTimeout：先把三兄弟摆到桌面上

刚入行做前端那几年，我对 JavaScript 计时事件的理解就是一招 setTimeout 吃遍天。后来一个页面倒计时在用户切后台再回来后差出十几秒，另一个轮询接口因为 setInterval 在慢网络下疯狂排队，我才意识到这类 API 表面上只是“延迟执行 / 每隔一段时间执行”，背后却连着事件循环调度、渲染帧和回调作用域这些老底子。这篇文章是从实际踩坑里整理出来的，覆盖 setTimeout、setInterval、requestAnimationFrame 三兄弟的差异，也会讲定时器回调里的 this、传参、异常处理，以及在 Vue/React 项目里怎么避免组件卸载后定时器继续跑的坑。适合刚把 JavaScript 基础语法过完、正开始写业务逻辑或网页小游戏的开发者；如果你已经写了两三年，也能在里面找到一些边界行为的印证。

1.1 setTimeout、setInterval、requestAnimationFrame 各自的定位

先说使用频率最高的 setTimeout。它的语义是“等一段时间后，把回调放进任务队列”，不是“等一段时间后立刻执行”。这个区别很多人一开始不重视，但在事件循环被长任务阻塞时就会翻车。setInterval 则是每隔固定时间往任务队列里添加回调，适合做轮询、心跳检测、秒杀倒计时这类“周期活儿”。不过真正做动画和网页游戏的人都知道，还有第三个更懂屏幕的计时器——requestAnimationFrame，它可以让你在浏览器渲染下一帧之前执行更新逻辑，从而实现跟显示器刷新率同步的画面。

这三个 API 表面上都是“和时间打交道”，但设计目标完全不同。setTimeout 适合一次性延时，setInterval 适合固定节奏的任务，requestAnimationFrame 则是为帧动画而生的。如果把三者混为一谈，很容易写出“看起来能用，一上线就出问题”的代码。

1.2 三兄弟差异速查表

为了让你一眼看清楚适用范围，我整理了一张简化版对照表：

从这个表能看出，requestAnimationFrame 和另外两个最大的差别是“跟不跟渲染走”。你如果只是定时请求一个接口，用 rAF 是浪费的，因为它每秒最多会被调用 60 到 120 次，远超你需要的频率。反过来，你要做 60fps 的逐帧动画，却用 setTimeout(loop, 16.7)，那误差和丢帧会让你很难受。

1.3 搜索“计时事件”时，为什么总混进 javascript:void(0)

很多人在搜“JavaScript 计时事件”时，会看到一些推荐词里带出 javascript:void(0)，比如 javascript:void(0) 和更奇怪的 javascript:void(document.title=document.cookie)。先说结论：void 运算符和计时事件没有关系，它是用来“对某个表达式求值，并强制返回 undefined”的运算符。

javascript:void(0) 这个写法在古早网页里很常见，主要作用是塞在 <a href> 里，让用户点击链接时不发生页面跳转。现在做项目，我不推荐继续用这种写法，因为一个链接如果没有真实地址，语义上就应该用 <button>，而不是用 <a href="javascript:void(0)">。至于后面跟了一长串 document.cookie 的那种写法，属于我在后面第 7 节要专门排雷的话题，这里先按下不表——它不是技巧，是危险信号。

2. 事件循环视角：setTimeout 为什么经常“不准点”

2.1 你设的不是“准点闹钟”，而是“到点排队”

有一次我排查一个倒计时页面，发现计时器整整延迟了两秒才触发。我当时很困惑，明明 setTimeout(fn, 1000)，怎么会慢一倍？后来查主线程才发现，页面上有一个图表库在初始化时同步跑了大量计算，把主线程堵住了一秒多。setTimeout 的回调在计时到点后，只是被放进了宏任务队列，它必须等当前执行栈清空、前面排队的任务都处理完，才有机会执行。

你可以把 JavaScript 主线程想象成银行柜台：setTimeout 相当于你预约“两分钟后我来办业务”，但到了时间点，只表示你可以在取号机上取号了，前面如果有正在办理的大爷，你还是得排队。这个模型解释了绝大多数“定时器不准”的问题。所谓不准，不是计时有 bug，而是执行时机被推迟了。

2.2 最小延迟、嵌套阈值和后台标签页节流

除了排队，还有几个内置限制会让回调“迟到”。浏览器规范要求，当 setTimeout 和 setInterval 出现嵌套调用（比如在回调里再创建定时器）超过一定层级时，最小延迟会被强制提升到 4ms。也就是说，你写 setTimeout(fn, 0) 连续嵌套很多次，实际间隔不会真的接近 0ms，而是会被限制在 4ms 左右。

另外，当页面切到后台标签页，浏览器为了省电会把定时器做节流处理。不同浏览器策略不同，有的把周期定时器合并成至少 1 秒触发一次，有的对不可见页面直接暂停某些高频率定时器。这也是为什么用前端倒计时切后台再回来往往会发现时间不对——不是别人改了你代码，而是定时器本身被浏览器降级了。

这里有一个实际测试方法，你可以自己跑一下：

javascript复制let last = performance.now();

function mark(label) {
  const now = performance.now();
  console.log(label, (now - last).toFixed(2), 'ms');
  last = now;
}

setTimeout(() => mark('t1'));
setTimeout(() => mark('t2'), 0);
setTimeout(() => mark('t3'), 4);

在不同浏览器里，t1 和 t2 的输出会有差异，但通常不会是你想象中的 0ms。知道这个规律后，我在业务里就不再较真于“准点触发”，而是用“尽量提前一点触发，到点再校验当前时间”的策略。

2.3 时间校正才是最稳妥的倒计时方案

上个月做一个秒杀倒计时，产品要求 23:59:59 之后必须立刻切成“已结束”。我第一版用 setInterval 每秒把剩余秒数减 1，本地测试没问题。但用户手机息屏一段时间后，再打开页面，剩余秒数比真实时间慢了十几秒，原因就是上面说的后台节流加休眠。

后来我改成只用一个定时器做“心跳”，每隔一秒读取一次 Date.now()，用服务端返回的截止时间减去当前时间来计算剩余秒数。这样即使定时器因为后台节流偶尔迟到，只要下一次执行时读取的是真实时钟，显示结果就能被纠正过来。真正的截止时间认准服务端，前端定时器只负责驱动界面刷新。

3. setInterval 的坑：重叠执行、误差累积与递归 setTimeout 解法

3.1 当任务是慢任务时，setInterval 会发生什么

setInterval 的危险之处在于它不管回调有没有执行完，到点就继续往队列里添加任务。举个例子，你设置 setInterval(fn, 1000)，如果某一次 fn 内部发了一个请求，网络特别慢，花了 3 秒才返回，那么在这 3 秒里，定时器又往队列里塞了另外两个 fn。等第一个请求返回后，就会连着执行多个相同回调，导致请求重叠、状态错乱、界面闪烁。

这种问题在轮询接口时特别常见。我见过一个数据大屏项目，每隔 5 秒请求一次报表数据，某次后端接口响应超过 5 秒，前端就出现了多个请求同时飞出去的情况。最终后端被压垮，前端控制台一串 429。问题是 setInterval 创建的，锅却不全在它身上——更准确地说，是我们选错了工具。

3.2 固定间隔误差的累积逻辑

setInterval 的另一个问题是误差只增不减。它的计时基准是从“创建定时器那一刻”开始推算的：第 1 次回调应该在第 1000ms，第 2 次在第 2000ms，第 3 次在第 3000ms。假设第 1 次回调因为主线程繁忙晚执行了 50ms，那第 2 次的“2000ms 目标”并不会往后顺延，它依然按原来的时间轴计算。

如果每次执行都有少量延迟，误差就会不断累积。对于秒杀倒计时、跑马灯这类对精度有要求的场景，这种误差是致命的。但话说回来，普通场景下轮询接口差几十毫秒没人能感知，你也不必过度设计。真正让我抛弃 setInterval 的，更多是第 3.1 节那种“任务排队叠车”的问题。

3.3 推荐用递归 setTimeout 代替 setInterval

我现在的习惯是：凡是回调里可能出现耗时操作，一律用递归 setTimeout，而不是 setInterval。核心思路很简单——上一次回调彻底执行完，再安排下一次。

javascript复制function poll() {
  fetch('/api/status')
    .then((res) => res.json())
    .then((data) => {
      render(data);
    })
    .catch((err) => {
      console.error(err);
    })
    .finally(() => {
      setTimeout(poll, 3000);
    });
}

setTimeout(poll, 3000);

这段代码里，无论请求是成功还是失败，都会在 finally 里安排下一次调用，所以不会因为某一次报错导致轮询中断。它的间隔语义也从“每隔 3 秒执行一次”变成了“上一次任务结束 3 秒后再执行下一次”，对于网络请求类任务来说，这个语义其实更合理。

如果你用 async/await 写，会更容易理解：

javascript复制async function poll() {
  try {
    const data = await fetch('/api/status').then((r) => r.json());
    render(data);
  } finally {
    setTimeout(poll, 3000);
  }
}

本质上，递归 setTimeout 把“定时”和“任务执行”解耦了：任务什么时候结束，下一次计时就从什么时候开始。而 setInterval 是“无论任务死活，时间一到就又来一个”，两者适用场景完全不同。

3.4 递归 setTimeout 也不是银弹

必须说清楚，递归 setTimeout 并非在所有场景都优于 setInterval。如果你需要一个“绝对严格、不考虑任务耗时”的周期器，比如在纯动画逻辑里做粒子发射，setInterval 反而更接近你的需求。而且递归 setTimeout 的每一次调用都会创建一个新的定时器对象，如果忘记清理，或者清理时机写错，同样会出现定时器越积越多的情况。

所以我的选择标准是：任务耗时可能变化，选择递归 setTimeout；任务耗时稳定且极短，setInterval 省事；任务与渲染帧相关，用 requestAnimationFrame。实际项目里大概有一半的场景，任务耗时都是不确定的，这也是我在新代码里很少再写 setInterval 的原因。

4. 回调函数里的 this 陷阱与闭包传参：箭头函数不是万能药

4.1 this 丢失的现场复盘

定时器回调里最常出现的笔误，是把一个对象方法直接传给 setTimeout，然后发现方法里的 this 全乱了。比如下面这段代码，很多人初看觉得没问题：

javascript复制const counter = {
  step: 1,
  tick() {
    console.log(this.step);
  },
};

setTimeout(counter.tick, 1000);

我在刚写 JavaScript 时也犯过同样的错，以为 setTimeout(counter.tick, 1000) 会输出 1，结果控制台打出来的是 undefined。原因很简单：setTimeout 调用传入的回调时，是在全局作用域里把它当普通函数调用的，此时函数内部的 this 指向全局对象，在严格模式下则是 undefined，而不是 counter。

处理方式有三种：第一种是用箭头函数包一层，让它捕获定义位置的 this；第二种是 setTimeout(counter.tick.bind(counter), 1000)；第三种是把方法改成箭头函数属性。个人建议优先用 bind 或者箭头函数包裹，因为这两种做法可读性最好，也方便在类组件里传参。

4.2 箭头函数的神秘感被高估了

社交媒体上很多人把箭头函数形容成“解决 this 问题的银弹”，其实它只解决了一类问题：箭头函数本身没有自己的 this，它继承的是定义时所在作用域的 this。如果你是在一个 Vue 组件的 setup 顶层定义定时器，箭头函数能拿到组件实例相关上下文；但如果你是在一个普通函数内部定义箭头函数，而那个普通函数的 this 本身就不对，那箭头函数继承到的也是个错误值。

我见过一个真实案例：有人在 methods 里写了个普通函数，里面用箭头函数创建 setInterval，以为这样能稳定访问组件 this。实际上这个普通函数在被 Vue 调用时可能已经有正确的 this 绑定，所以箭头函数跟着没错；但如果把它抽出来单独导出，再被事件回调调用，组件 this 就丢了。要避免这类问题，核心是明确“函数被谁调用”，而不是迷信某个语法。

4.3 给定时器回调传参的三种姿势

第一反应可能是用闭包：

javascript复制function say(word) {
  console.log(word);
}

setTimeout(() => say('hello'), 1000);

这种没问题。但需要注意的是，闭包会捕获外层变量，如果你在外层循环里创建定时器，可能会踩到经典的 var 变量共享坑。第二个方案是使用 setTimeout 的额外参数——从较新的现代浏览器开始，setTimeout(fn, delay, param1, param2) 可以在延迟之后把后面的参数传给回调：

javascript复制setTimeout(say, 1000, 'hello');

第三个方案是 bind：

javascript复制setTimeout(say.bind(null, 'hello'), 1000);

这三个方案眼熟的人一眼就能看出来，它们其实也对应了 JavaScript 里“延迟绑定参数”的三种常规思路。闭包写法最灵活，原生额外参数最简洁，bind 最大的优点是不用包一层箭头函数，代码看起来更平。

4.4 回调抛异常后，定时器到底会不会断

这是一个容易被忽视的问题：如果 setInterval 的回调内部抛了一个错，这个定时器会被自动清除吗？答案是不会。setInterval 一旦创建，就会持续触发，直到你手动调用 clearInterval，或者页面销毁。回调内部的异常只会中断当前这一次执行，不会影响后续的周期。

对于递归 setTimeout 则相反——如果回调里抛了异常，且你没有处理，那么后续的 setTimeout 就不会被安排，轮询链路就断了。很多线上问题就是这么来的：某次接口返回异常数据，回调在解析时就抛错了，用户看到的是数据不再更新，控制台可能只有一条红色报错。解决办法是在回调内部统一加 try/catch/finally，把“下一次任务”安排到 finally 里，这样无论成功失败都能继续跑。如果希望连续失败 N 次后自动停止，再维护一个失败计数器即可。

5. requestAnimationFrame：页面游戏和动画场景的正确计时姿势

5.1 从热搜里的“网页游戏”说起

相关热搜里有一条很典型：“没问题!我为你用 html5 + javascript(网页游戏最常用的技术)编写了一个简易的……”。这反映出现在很多人接触 JavaScript 的动机，是想做网页小游戏或交互页面。而做游戏就避不开“主循环”这个概念：每帧更新状态、每帧渲染画面。最朴素的做法是 setInterval(gameLoop, 1000 / 60)，但这样做有几个问题。

显示器刷新率不是固定 60Hz，有的机器是 75Hz、120Hz 甚至更高。setInterval 固定在 16.67ms，显然无法适配所有刷新率。其次，setInterval 的回调落在宏任务队列里，跟浏览器绘制时机并不同步，可能出现界面绘制一半时状态被更新的情况，视觉上表现为撕裂感或卡顿。requestAnimationFrame 能直接解决这两个问题，它会由浏览器在每次绘制前调用，和屏幕刷新率保持一致。

5.2 rAF 的常用主循环写法

一个最基础的游戏循环长这样：

javascript复制let lastTime = 0;
let totalSeconds = 0;

function frame(timestamp) {
  const delta = (timestamp - lastTime) / 1000;
  lastTime = timestamp;

  // update 和 render 分别处理逻辑和绘制
  update(delta);
  render();

  requestAnimationFrame(frame);
}

requestAnimationFrame(frame);

第一帧的 timestamp 可能不是从 0 开始，所以 lastTime 初始化成 0 后，第一次 delta 通常会偏大。我会做一层保护：

javascript复制function frame(timestamp) {
  if (!lastTime) {
    lastTime = timestamp;
  }
  const delta = Math.min((timestamp - lastTime) / 1000, 0.1);
  lastTime = timestamp;
  // ...
}

Math.min 把最大间隔限制在 0.1 秒内，防止用户切回页面时，一帧之间隔了几秒，导致运动物体瞬移。

5.3 什么时候该用 rAF，什么时候别用

requestAnimationFrame 不是所有“定时业务”的替代品。你用它轮询接口，等于每秒动辄触发几十次请求，这在多数场景下是不可接受的。正确的使用边界是：需要流畅更新画面、更新位置、更新图表动画、做游戏循环时，优先 rAF；只需要固定间隔做数据检查时，仍然用递归 setTimeout。

还有一个真实体验是：如果你做的是一个滚动进度条或拖拽吸附效果，直接操作 scroll 事件已经不够，用 rAF 把高频事件合并起来才是正路。典型写法是：

javascript复制let ticking = false;

window.addEventListener('scroll', () => {
  if (!ticking) {
    requestAnimationFrame(() => {
      updateScrollUI();
      ticking = false;
    });
    ticking = true;
  }
});

这样就把原本每帧可能触发很多次的滚动事件，压缩成每帧最多一次 UI 更新。综合来看，requestAnimationFrame 是最“懂浏览器”的计时方式，只是很多只写业务的人长期不用它，思维被 setTimeout 锁住了。

6. 真实项目里的计时器管理：从 Vue 组件的 ElMessage 报错说起

6.1 热搜里的“为什么 ElMessage 还是提示未定义”

热搜里有一条挺有代表性的：“vue javascript项目,自动导入elementplus,为什么elmessage还是提示未定义”。很多人配置了 unplugin-auto-import 和 ElementPlusResolver，模板里的 <el-button> 能正常渲染，但一旦在 JS 里写 ElMessage.success('保存成功')，就报 ElMessage is not defined。

这问题跟计时事件没有直接关系，但经常一起出现——因为定时器回调里也常常要弹提示。如果这条提示写在 setup 顶层，很多自动导入配置能帮你补上 ElMessage；但如果把它移到一个独立的定时器回调、工具函数或异步 handler 里，而这个文件没有被自动导入逻辑覆盖，就会报未定义。解决办法很简单：显式从 element-plus 导入，不要依赖“魔法”：

javascript复制import { ElMessage } from 'element-plus';

setTimeout(() => {
  ElMessage.success('操作成功');
}, 1000);

框架的自动导入只解决一部分开发体验问题，对于 JS 里手动引用的模块，显式导入永远是最可靠的兜底。

6.2 组件卸载后，定时器为什么还在跑

接着说一下定时器在组件生命周期里的经典翻车现场。我在 Vue 3 里写过一个数据刷新逻辑，onMounted 里启动 setInterval，页面数据确实在更新，但路由跳到别的页面后再回来，发现上一个页面还在发请求，控制台还有 Vue 的警告。问题就出在：我只启动了定时器，却忘了在组件卸载时把它清掉。

清除方式如下：

javascript复制import { onBeforeUnmount, onMounted, ref } from 'vue';

const count = ref(0);
let timer = null;

function start() {
  timer = setInterval(() => {
    count.value += 1;
  }, 1000);
}

function stop() {
  if (timer) {
    clearInterval(timer);
    timer = null;
  }
}

onMounted(start);
onBeforeUnmount(stop);

React 函数组件里也有同样的逻辑，区别是用 useEffect 的 cleanup 函数：

javascript复制useEffect(() => {
  const id = setInterval(() => {
    setCount((c) => c + 1);
  }, 1000);
  return () => clearInterval(id);
}, []);

这种“创建时登记，销毁时清理”的思路，无论框架怎么变都不会过时。

6.3 我积累的一套定时器管理习惯

踩过几次定时器泄漏的坑之后，我给自己定了几条硬规矩，你可以直接抄：

• 每次创建定时器，立刻把返回的 id 存进变量，不要随手丢弃。
• 在组件卸载、路由离开、弹窗关闭等生命周期钩子里集中执行清理。
• 回调内部不要直接修改 DOM，尽量只更新数据状态；如果非改不可，要判断目标元素是否还存在。
• 对耗时不确定的任务，使用递归 setTimeout 而不是 setInterval，避免任务重叠。
• 回调加入执行锁，防止因为手动触发和定时任务同时运行导致竞态。
• 如果一个定时器任务可能被多个按钮触发，先 clear 再重新创建。

这些规矩看起来平平无奇，但绝大多数线上定时器 bug 都逃不出这几条。比如“倒计时越跑越快”，多半是用户在某个按钮上点击了多次，每个按钮都创建了一个新定时器，旧定时器没清掉。先 clear 再 set，能解决一大批类似问题。

7. 几个高频热搜词的连带排雷：危险写法、运行时错误与新手路线

7.1 看到带上 cookie 的 javascript:void 写法，直接拉黑

不知道你有没有在热搜里看到过一长串 javascript:void(...) 后面跟 document.cookie 的写法。第一次见到时我也很好奇，查了一下才明白，这种代码不是常规技巧，而是某些页面用来试探可执行脚本的测试载荷。它的思路是把包含会话信息的 document.cookie 塞进页面标题或其它位置，再配合第三方脚本读取，以判断当前页面是否存在可利用的注入点。

这种代码在正经项目里没有任何使用价值，更不应该出现在你收藏的代码片段里。看到类似写法要警惕，不能因为“能运行、控制台没报错”就觉得是个冷门黑魔法。我在团队里定了一条规矩：任何从网上复制来的带 javascript: 协议、带 document.cookie、带动态拼接执行字符串的代码，先问来源，再评估风险，拿不准直接扔。

同理，setTimeout 和 setInterval 都支持把字符串当作第一个参数传入，历史上也出现过不少利用这个特性做的攻击，比如把用户输入的内容拼进定时器字符串去执行。现在的代码规范都不建议再用字符串形式的定时器，你应该始终传入函数。这不仅是风格问题，更是安全底线。

7.2 计时器回调里的运行时报错，怎么处理才不容易翻车

前面说了，setInterval 回调内部抛错不会终结定时器，所以异常可能反复出现，控制台会刷屏。而递归 setTimeout 恰恰相反，一个未捕获异常就可能让整条轮询链路断掉。应对策略是给回调包上 try/catch，并在 finally 里安排下一次任务。更稳妥的做法是加一个连续失败计数，连续失败超过 N 次就主动停掉，避免后端异常时前端还在无限重试。

我处理“运行时报错”热词时经常提到一点：要学会区分“当前回调的错误”和“定时器本身的错误”。定时器回调里若抛出异常，只会记录在全局错误事件里，不会让定时器消失；但如果你用 async 函数作为回调，错误会变成 Promise rejection，如果没人处理，你会看到 unhandledrejection，而不是普通的 error。两种情况排查方式完全不同，新手很容易被误导。

7.3 新手总在纠结“学 JavaScript 还是 Python”

搜索词里还有一条经典纠结：“javascript python 学哪个”。我给不出通吃答案，因为路线取决于目标。如果你的目标是写网页、做前端、做全栈，或者想照着热搜里那些网页游戏案例练手，那就先学 JavaScript。它是浏览器里唯一能直接运行的语言，学习反馈最快：打开一个 .html 文件就能看到结果。如果目标是数据分析、机器学习或者处理 Excel 之类的工作流，Python 更顺手。但这两者不是互斥的，JavaScript 的语言基础和编程思维完全可以迁移到 Python 上。

我的建议很简单：不要纠结太久，选定一个主攻，先啃完基础语法，然后用“计时事件”这种小模块做几个能运行的小案例。比如用 setTimeout 做一个延迟提示，用递归 setTimeout 做轮询，用 requestAnimationFrame 做一个移动的小方块。项目里的坑踩得越多，你对 JavaScript 的理解就越深。至于书单，虽然《你不知道的 JavaScript》和《JavaScript 高级程序设计》都是很好的进阶读物，但千万别光看不动手。

最后再分享一个小技巧：拿到一个新功能，先问自己“它是需要跟屏幕刷新同步，还是只需要固定间隔干活”。前者找 requestAnimationFrame，后者再从递归 setTimeout 和 setInterval 里挑。这个简单的提问方式，帮我少踩了很多计时相关的坑。