17370845950

JavaScript定时器非实时调度器，而是事件循环中延迟触发的异步任务；setTimeout保证至少延迟后执行，setInterval仅按间隔向队列添加回调，均不精确。

JavaScript 定时器不是实时调度器，而是「事件循环中延迟触发的异步任务」——setTimeout 和 setInterval 都不保证精确时间，只保证「至少延迟这么久之后才可能执行」。

为什么 setTimeout 有时比设定时间晚很多？

定时器回调被放入「宏任务队列」，必须等当前调用栈清空、且上一个宏任务（包括其他 setTimeout、setInterval、I/O 回调等）执行完后，才会被取出来执行。如果主线程长时间被阻塞（比如大数组排序、死循环、同步 AJAX），定时器就会严重滞后。

• 常见错误现象：setTimeout(() => console.log('done'), 10) 在页面卡顿时延迟几百毫秒甚至几秒才输出
• 使用场景：适合「延迟一次执行」，比如防抖初始延迟、延后初始化、模拟加载完成
• 性能影响：不会持续占用资源；但若传入闭包过大或引用 DOM 节点，可能阻碍 GC
• 注意：setTimeout 返回一个数字 ID，可用于 clearTimeout 取消；传入非函数值（如字符串）会触发隐式 eval，禁止使用

setInterval 的回调真的每 N 毫秒执行一次吗？

不是。它只是「每隔 N 毫秒向任务队列添加一次回调」，但如果前一次回调尚未执行完（比如耗时 > N ms），下一次就会被积压，导致连续触发或跳过。浏览器也可能在标签页后台时自动降频（如 Chrome 将最小间隔限制为 1000ms）。

• 常见错误现象：用 setInterval(() => { heavyTask(); }, 100) 导致界面卡死或任务堆积
• 使用场景：轮询状态（需配合节流）、动画帧协调（但更推荐 requestAnimationFrame）、心跳检测（应搭配超时重连逻辑）
• 参数差异：第三个及以后参数可作为回调的参数传递，如 setInterval(cb, 1000, 'a', 123) 等价于 cb('a', 123)
• 必须手动 clearInterval，否则内存泄漏风险高；尤其在 React/Vue 组件卸载、DOM 移除时容易遗漏

如何避免 setInterval 的累积执行和内存泄漏？

优先用 setTimeout 递归代替 setInterval，能确保前一次任务结束再安排下一次，也便于动态调整间隔或提前终止。

let timerId = null;
const startPolling = () => {
  const poll = () => {
    fetch('/api/status')
      .then(res => res.json())
      .then(data => {
        if (data.ready) {
          console.log('done');
          return;
        }
        timerId = setTimeout(poll, 500); // 下次仅在本次成功后启动
      })
      .catch(() => {
        timerId = setTimeout(poll, 2000); // 出错时降频重试
      });
  };
  timerId = setTimeout(poll, 0);
};

// 清理
const stopPolling = () => {
  if (timerId !== null) {
    clearTimeout(timerId);
    timerId =
 null;
  }
};

• 不要依赖 setInterval 做精确倒计时或音视频同步
• 在单页应用中，务必在组件 unmount 或 destroyed 钩子中清理定时器 ID
• Node.js 环境下，setInterval 不受页面可见性影响，但长期运行仍需考虑内存引用和异常兜底

真正难的不是调用定时器，而是判断「该不该用」以及「怎么安全收尾」——尤其是跨异步边界、嵌套作用域、动态生命周期场景下，clearTimeout/clearInterval 的时机和引用管理，比启动定时器更容易出错。