JavaScript定时器完全指南：从setTimeout到requestAnimationFrame的选型与避坑

聊到 JavaScript 定时器，我先说个真实经历：之前给一个活动页做倒计时，上线没几天就收到反馈说“倒计时偶尔会跳变，有时候还停住不走”。我当时第一反应是数据算错了，可排查了半天，最后发现问题压根不在业务逻辑，而是出在我用 setInterval 跑倒计时这件事本身。那次之后我才意识到，定时器这个 API 虽然简单到每个前端都写过，但真正把它用对、用好，其实藏着不少容易被忽略的细节。

这篇就完整聊聊我对 JavaScript 定时器的一线使用心得：从 setTimeout、setInterval 和 requestAnimationFrame 的选型对比，到定时器“为什么不准”背后的运行机制，再到实际项目里的清理策略和防抖节流实现。不管你是刚接触前端的新人，还是写了好几年页面但没仔细抠过定时器原理的开发者，这篇应该都能帮上忙。

定时器三兄弟选型：setTimeout、setInterval、requestAnimationFrame 到底该用谁

很多刚入行的人会把“定时器”和 setInterval 画等号，一说到定时任务就 setInterval，一说到动画就 setTimeout 硬凑。实际上浏览器环境里我们常用的定时器核心有三个，它们解决的问题各有侧重，选错了后续大概率要还技术债。

setTimeout：一次性的延迟执行

setTimeout 的语义是“等一段时间之后再执行一次”。第二个参数表示延迟时间，单位是毫秒，但要注意它代表的是“至少等多久”，而不是“精确等多久”。这个区别非常关键，后面我会专门讲为什么。

一个最基本的用法：

javascript复制const timer = setTimeout(() => {
  console.log('延迟 1000ms 后执行');
}, 1000);

// 取消执行
clearTimeout(timer);

setTimeout 的典型场景包括：按钮点击后的防抖、请求失败后的重试延迟、弹窗自动关闭、以及一些“本轮任务结束后再处理”的调度需求。它不用循环，跑完一次就结束，不会像 setInterval 那样在后台疯狂堆积。

setInterval：固定间隔的周期执行

setInterval 的语义是“每隔一段时间执行一次”，看起来好像天然适合做轮询、倒计时、动画，但它有两个致命问题：第一是执行间隔并不稳定，第二是它只关心“到没到时间”，不关心上一次执行完没有。如果上一次回调执行了 1.5 秒，而你设置的间隔是 1 秒，那下一次回调并不会等到上次执行完再等 1 秒，而是会在合适的时机排进队列。这就会造成两种情况：要么回调相互重叠，要么多个回调连续执行，看起来像“卡顿后突然加速”。

基础用法：

javascript复制const interval = setInterval(() => {
  console.log('每 1000ms 执行一次');
}, 1000);

// 清理
clearInterval(interval);

我现在的习惯是：轮询接口时，尽量不用 setInterval，改用递归 setTimeout。这样每轮请求完成后再安排下一轮，天然避免了回调重叠，后面会给出封装示例。

requestAnimationFrame：跟着浏览器刷新节奏走

严格来说 requestAnimationFrame 不是定时器，但它在动画场景里就是用来取代 setTimeout/setInterval 的正牌方案。它的执行频率跟屏幕刷新率一致，通常是每秒 60 次，而且浏览器会在页面处于后台时自动暂停调用，省电省资源。

javascript复制let rafId;

function animate() {
  // 更新动画状态
  // ...
  rafId = requestAnimationFrame(animate);
}

rafId = requestAnimationFrame(animate);
// 取消
cancelAnimationFrame(rafId);

用 requestAnimationFrame 做动画的好处不只是流畅，还在于它跟浏览器的渲染管线是同步的。你在 rAF 回调里改 DOM，浏览器会在下一帧绘制时用上，不会出现 setTimeout 改完 DOM 但过了半天才绘制的情况。

三者对比与我的选型判断

如果只是做一个“每 5 秒刷新一次信息”的简单功能，setInterval 直接上问题不大。但凡是动画、倒计时、高频率状态更新，rAF 和递归 setTimeout 是更稳的选择。这是我踩过几次坑之后总结出来的铁律。

定时器为什么不准：事件循环、嵌套限制与后台节流

前面卖了好几次关子，现在讲核心问题：为什么定时器不能“准时”。这背后牵扯到 JavaScript 的运行机制，不搞清楚这点，你在写倒计时、轮询、游戏循环时很容易被现实打脸。

定时器不是“到点执行”，而是“到点入队”

JavaScript 是单线程的，同一时间只能执行一段代码。浏览器通过事件循环（event loop）维护一个任务队列，JS 主线程执行完当前任务后，才会从队头取出下一个任务执行。setTimeout 的作用不是“多少毫秒后立刻运行”，而是“多少毫秒后，把回调函数放进任务队列”。

这里有个很生活化的类比：你去餐厅吃饭，店员告诉你“大约等位 20 分钟”。这 20 分钟意味着 20 分钟后会去看一眼有没有空桌，如果有就安排你入座，如果没有还得继续等。在你前面还有一大堆排队的客人，每个入座吃完都可能耽误时间。定时器的“20 分钟”实际上就是“最早 20 分钟后给你安排入队”，至于真正执行回调的时间，取决于当时主线程忙不忙、任务队列里排了多少活。

所以你会发现，如果页面里有一个特别耗时的任务（比如大量 DOM 操作、一个复杂计算），就算 setTimeout 设了 0 毫秒，也得等这个耗时任务结束才能轮到它。这不是浏览器偷懒，而是单线程模型的必然结果。

嵌套 setTimeout 的 4ms 限制

不知道你有没有做过这种实验：循环里用 setTimeout 来模拟高频率调用，比如 setInterval 设 0 毫秒，或者递归 setTimeout 设 0 毫秒，然后把时间点打出来，你会发现实际间隔根本到不了 0，基本稳定在 4ms 左右。这不是你电脑的问题，而是 HTML 规范里明确写的：当 setTimeout 嵌套超过 5 层时，浏览器会把最小延迟时间限制到 4ms。

这个机制的目的，主要是防止某些人用 setTimeout(0) 恶意阻塞主线程。在校园网环境里还好，放到真实浏览器里，你如果做每秒 1000 次以上的 setTimeout 调用，很快就会被限流。

页面不可见时的定时器节流

还有一个大坑是浏览器对后台标签页的节流。页面切到后台后，为了省电，Chrome 会把定时器的执行频率降到每秒一次，甚至在某些场景下直接休眠。对用户体验来说，这意味着你前台测试一切正常的定时器，切出去再切回来，时间线已经和真实时间差出十万八千里。

我用过一次印象特别深的翻车案例：写一个秒杀倒计时，用 setInterval 每秒改一次剩余秒数。用户把标签页切到后台挂了几分钟，回来发现倒计时还停留在切换前的状态，好一会儿才恢复正常。原因是后台节流让 setInterval 的触发频率降到了 1 分钟 1 次，页面根本不知道真实时间已经过去了多久。

这种场景的解决方案只有一个：不要在定时器里做“累加/递减”，而是用“时间戳差值”来推算剩余时间。定时器只负责刷新 UI，不负责记录时间。

javascript复制function startCountdown(targetTime, updateFn) {
  const timer = setInterval(() => {
    const remain = targetTime - Date.now();
    if (remain <= 0) {
      clearInterval(timer);
      updateFn(0);
      return;
    }
    updateFn(remain);
  }, 200);
}

这样写的好处是：即使定时器后台被节流、甚至暂停，只要恢复执行，就会用当前真实时间重新计算剩余值，UI 立刻校准，用户不会看到跳变的倒计时。这个我在好几个活动页里验证过，效果非常稳。

定时器使用中最容易翻车的四个场景与排查思路

光知道 API 和机制还不够，定时器真正容易让人掉头发的是各种副作用。这里挑四个我见人踩过无数次的坑，每个都附上排查思路，方便你下次直接照着对照。

this 指向悄悄变了

setTimeout 里的回调函数其实是被当作普通函数调用的，所以它内部的 this 不指向你定义时的对象。非严格模式下，this 指向 window；严格模式下，直接是 undefined。这个在 React 类组件里是最常见的翻车点：

javascript复制class Counter extends React.Component {
  start() {
    // 这里的 this 已经丢了
    setTimeout(function () {
      console.log(this); // undefined 或 window
    }, 1000);
  }
}

解决方案也不复杂，三种任选：箭头函数、bind、或者在外面提前存一下 this。

javascript复制setTimeout(() => {
  console.log(this); // 箭头函数不会改变 this 指向
}, 1000);

// 或者
setTimeout(function () {
  console.log(this);
}.bind(this), 1000);

我推荐箭头函数，语义直观，写起来也省事。如果你在项目里发现定时器回调里拿不到预期的 this，第一反应就去看这里有没有普通 function。

定时器 ID 被覆盖导致无法清理

这是一个非常隐蔽的 bug。很多人会这样写：

javascript复制let timer = null;

function start() {
  // 先清掉旧的，再启动新的，这是正确姿势
  if (timer) {
    clearTimeout(timer);
  }
  timer = setTimeout(() => {
    console.log('执行');
  }, 1000);
}

但如果你漏掉了先 clearTimeout，连续调用 start() 两次，旧的 timer ID 就被新的覆盖了。等你想清理的时候，只能清掉最后一次创建的定时器，前面的定时器会继续在后台执行，产生重复请求、重复渲染等一堆问题。我在排查前端搜索框的重复请求时，十次里有七八次是这个问题。

排查思路很直接：在代码里搜 setTimeout/setInterval 的调用处，看是否每次启动前都做了 clear；如果没做，先补上再观察。

循环里 setTimeout 的闭包取错值

这个坑面试常考，但工作中也真的会遇到。用 var 在循环里注册多个 setTimeout，回调打印出来的变量值永远是最后一个：

javascript复制for (var i = 0; i < 5; i++) {
  setTimeout(function () {
    console.log(i); // 输出 5 5 5 5 5
  }, 1000);
}

原因是函数作用域和闭包：所有回调共享同一个 i，而循环结束时 i 已经变成 5。把 var 改成 let 是最省事的解法，因为 let 是块级作用域，每一轮循环都生成一个新的 i。如果不方便用 let，也可以用立即执行函数包一层，把 i 作为参数传进去。

内存泄漏：定时器在组件销毁后依旧存活

定时器不清理，最大的问题不是多执行几次，而是内存泄漏。React 或 Vue 组件都讲究“卸载后不再操作”，但如果定时器没清，回调依然会执行，可能触发 setState、修改 DOM、发起请求，甚至在闭包里持有整个组件实例，导致组件明明已经卸载，内存却始终释放不掉。

React 函数组件里的典型写法：

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

这个 return 回调就是组件卸载时的清理函数。我见过一些老代码，useEffect 里只写了 setInterval，不写清理函数，换页之后定时器还在跑，后台就一直在 setState。时间一长，页面越来越卡，内存占用越飙越高。排查方法也简单：打开 DevTools 的 Performance 面板，录一段页面操作，看有没有大量没被回收的 Interval 对象。

工程化实践：在真实项目里规范地管理定时器

单次定时器好写，难的是在大型项目里保证所有定时器都能被创建、清理、追踪。这里分享几个我在 React 和 Vue 项目里常用的封装方案，以及一个管理多个定时器的工具类思路。

React 下的 useTimeout 与 useInterval 封装

函数组件里直接用 setTimeout，最大的问题是依赖管理和清理逻辑容易漏。封装成自定义 Hook，一是统一清理，二是让代码语义更清晰。

一个简单的 useInterval 封装：

javascript复制function useInterval(callback, delay) {
  const savedCallback = useRef();

  useEffect(() => {
    savedCallback.current = callback;
  }, [callback]);

  useEffect(() => {
    if (delay === null || delay === undefined) {
      return;
    }
    const id = setInterval(() => {
      savedCallback.current();
    }, delay);
    return () => clearInterval(id);
  }, [delay]);
}

特点是把 callback 放在 ref 里，这样每次渲染时传入新的 callback，不会因为函数引用变化而重建定时器。delay 作为依赖，只会在延迟值变化时重建。用的时候：

javascript复制useInterval(() => {
  // 每 1 秒执行一次
}, 1000);

同理可以封装 useTimeout，在延迟执行后触发一次回调。这类 Hook 网上有很多版本，但核心思路都一样：用 useEffect 管理生命周期，用 useRef 保存最新回调，返回清理函数。

Vue 3 组合式方式里的定时器清理

Vue 3 的 setup 语法里，可以用 onUnmounted 清理定时器，也可以把整个逻辑封装成 composable：

javascript复制import { onUnmounted } from 'vue';

export function useCountdown(duration, onTick) {
  const timer = setInterval(() => {
    onTick(Date.now());
  }, 200);

  onUnmounted(() => {
    clearInterval(timer);
  });
}

也可以直接在下一次 setup 里先清理再创建。函数组件的生态里，本质就是“创建和销毁要成对出现”，无论什么框架，这一原则都不会变。

一个管理多个定时器的 TimerManager

实际项目里经常会遇到“页面上同时挂着好几个轮询/倒计时”的情况。与其在组件里散落一堆 timer 变量，不如用一个统一的 TimerManager 来管理：

javascript复制class TimerManager {
  timers = new Map();

  setTimeout(key, fn, delay) {
    this.clear(key);
    const id = setTimeout(() => {
      this.timers.delete(key);
      fn();
    }, delay);
    this.timers.set(key, id);
  }

  setInterval(key, fn, interval) {
    this.clear(key);
    const id = setInterval(fn, interval);
    this.timers.set(key, id);
  }

  clear(key) {
    const id = this.timers.get(key);
    if (id) {
      clearTimeout(id);
      clearInterval(id);
      this.timers.delete(key);
    }
  }

  clearAll() {
    for (const key of this.timers.keys()) {
      this.clear(key);
    }
  }
}

这样做的收益是明显的：所有定时器都有名字，不会被“孤儿定时器”困扰；组件卸载时只需要调一次 clearAll，不用去翻每个定时器的 ID。我自己的项目里接手过遗留代码，用了这个方案之后，“定时器越跑越多”的诡异问题基本绝迹了。

防抖与节流：定时器的两个经典应用

理解定时器之后，再去看防抖和节流就会觉得特别自然。防抖（debounce）是把连续触发的事件合并成一次执行，核心就是“每次触发都重置上一次定时器”；节流（throttle）是限制触发频率，核心是“在时间窗口内只执行一次”。

防抖简单实现：

javascript复制function debounce(fn, wait) {
  let timer = null;
  return function (...args) {
    if (timer) {
      clearTimeout(timer);
    }
    timer = setTimeout(() => {
      fn.apply(this, args);
    }, wait);
  };
}

节流的简单实现：

javascript复制function throttle(fn, interval) {
  let last = 0;
  return function (...args) {
    const now = Date.now();
    if (now - last >= interval) {
      last = now;
      fn.apply(this, args);
    }
  };
}

推荐在项目里优先使用 lodash 的 debounce/throttle 或者 Rambda 的对应方法，毕竟实现里还有更多边界情况要考虑。但理解它们背后的定时器运作方式，对排查线上问题非常有帮助。

setTimeout(0) 与事件循环：底层调度机制的实际影响

最后聊聊 setTimeout(0) 这个人人都写过、但很多人没想过它为什么有用的用法。有些人以为 setTimeout(0) 就是“立刻执行”，其实并不是。

宏任务与微任务的执行顺序

setTimeout 注册的回调属于宏任务，而 Promise.then、MutationObserver 这些属于微任务。事件循环的执行过程是：先执行当前宏任务里的同步代码，然后清空所有微任务，最后才轮到下一个宏任务。所以 setTimeout(0) 的回调永远排在微任务后面。

你可以粘到控制台验证一下：

javascript复制console.log('1 同步');

setTimeout(() => {
  console.log('3 setTimeout');
}, 0);

Promise.resolve().then(() => {
  console.log('2 Promise');
});

// 输出顺序：1 同步 -> 2 Promise -> 3 setTimeout

这个顺序在面试里常考，在实际工程里的价值也没那么玄乎，核心是：如果你想让某段代码“在浏览器渲染之前做”，用微任务；如果想“在渲染之后做”，用宏任务。

setTimeout(0) 的典型应用场景

常见的场景有三个。第一个是拆分长任务：一个大计算任务会导致页面卡死，把它按时间片拆成小块，每块用 setTimeout(0) 丢进任务队列，让浏览器有机会插队渲染，页面就不会一直白屏。第二个是事件循环顺序调整：有时候你需要在当前脚本执行完之后、下一个渲染周期之前，调整 DOM 或做一些测量，把代码塞进 setTimeout(0) 基本能满足。第三个是避免递归爆栈：把递归改成循环 + setTimeout(0)，可以防止调用栈溢出，让计算过程分批推进。

什么情况下不要用 setTimeout(0)

如果你发现自己在循环里大量使用 setTimeout(0)，比如 for 循环里面给每个元素都 setTimeout(0)，那大概率有问题。浏览器每执行一个宏任务都会做一次渲染检查，大量 setTimeout(0) 会频繁打断渲染，反而让页面更卡。而且前面提过，嵌套超过 5 层会被限流到 4ms，你想要的“0 延迟”也根本达不到。

如果是动画，还是优先用 requestAnimationFrame；如果是高频率数据更新，考虑用微任务或者把状态交给框架批量更新。setTimeout(0) 是调度工具，不是优化引擎，用错了地方适得其反。

关于定时器暂停的补充

在实际项目里还有一类需求：暂停和恢复定时器。setTimeout 本身没有 pause 方法，只能 clear 后重新创建。比较优雅的做法是记录任务开始时间，暂停时算出剩余时间，恢复时用剩余时间重新 setTimeout，这样可以做到无缝暂停。

javascript复制class DelayTask {
  constructor(fn, delay) {
    this.fn = fn;
    this.delay = delay;
    this.startTime = Date.now();
    this.timer = setTimeout(() => {
      this.fn();
      this.timer = null;
    }, delay);
  }

  pause() {
    if (!this.timer) return;
    this.remain = this.delay - (Date.now() - this.startTime);
    clearTimeout(this.timer);
    this.timer = null;
  }

  resume() {
    if (this.timer) return;
    if (this.remain <= 0) {
      this.fn();
    } else {
      this.timer = setTimeout(() => {
        this.fn();
        this.timer = null;
      }, this.remain);
    }
  }
}

这个模式在音乐播放器、视频弹幕、游戏暂停等场景里很实用。核心思想就是利用时间戳来记录剩余时间，因为定时器本身不具备暂停能力。

我个人在实际操作中的一个习惯是：所有跟时间有关的逻辑，都不要依赖定时器的 tick 次数，而是用 Date.now() 或者 performance.now() 来感知真实时间。定时器只负责“到点提醒”，至于到底过去了多久，请相信系统时钟。这样写出来的代码在后台切换、系统休眠、移动端省电模式下都不会出大乱子。最后再分享一个小技巧：开发调试的时候，给 setTimeout 包一层日志函数，打印定时器的注册位置和执行时机，排查起“某个定时器从哪里来的”这种问题会轻松很多。定时器虽小，用好了是利器，用不好就是线上事故的温床。