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，能确保前一次任务结束再安排下一次，也便于动态调整间隔或提前终止。
立即学习“Java免费学习笔记（深入）”；
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 的时机和引用管理，比启动定时器更容易出错。
