17370845950

setTimeout只执行一次，setInterval反复触发；前者执行完自动销毁，后者无视回调状态持续入队，易堆积卡死；推荐用setTimeout递归实现可控轮询。

setTimeout 只执行一次，setInterval 会反复触发

setTimeout 是“等一会儿干一次”，比如按钮点击后禁用 1 秒、防抖时清掉上一个定时器再设新定时器；setInterval 是“每隔一会儿就干一次”，比如每秒刷新倒计时、轮询接口状态。

关键区别不在语法多像，而在执行机制：setTimeout 执行完就自动销毁；setInterval 不管你回调有没有跑完、有没有报错，到点就继续塞进任务队列——容易堆积、跳帧、甚至卡死。

• setTimeout 返回一个数字 ID，必须用 clearTimeout(id) 才能取消
• setInterval 同样返回 ID，但必须配对使用 clearInterval(id)，漏掉就会内存泄漏
• 即使设 delay 为 0，两者都只是“尽快执行”，不是“立刻执行”——它们都进宏任务队列，得等当前同步代码跑完

别直接用 setInterval 做精准倒计时或心跳

如果回调函数执行时间 > 间隔（比如 setInterval(fn, 1000) 里 fn 耗时 1200ms），下一次调用不会被跳过，而是立即补上——结果就是连续两三次密集执行，之后又延迟，节奏全乱。

更稳的做法是用 setTimeout 递归：

let timerId = null;
function tick() {
  console.log("tick at", Date.now());
  timerId = setTimeout(tick, 1000);
}
timerId = setTimeout(tick, 1000); // 启动

这样每次都是上一轮结束才开始算下一轮延时，节奏可控，也不怕回调变慢。

• 真实项目中，轮询 API、模拟动画帧、维持 WebSocket 心跳，都推荐这种写法
• setInterval 更适合轻量、确定不阻塞的场景，比如单纯更新页面上的秒数显示（且 DOM 操作极简）

参数和错误处理差异很大

setTimeout 和 setInterval 都支持传参，但老式字符串写法（如 setTimeout("alert(1)", 1000)）已废弃，不仅不安全，还无法捕获错误。

务必用函数引用 + 后续参数形式：

setTimeout(() => {
  console.log("done");
}, 500);

// 或带参数
setTimeout(console.log, 500, "hello", "world");

• setInterval 的回调一旦抛错，定时器不会停，错误会被吞掉（只在控制台报错），后续仍照常触发
• setTimeout 抛错则只影响这一次，不影响其他定时器
• 若需错误兜底，建议在回调里包 try...catch，尤其在 setInterval 中

清除定时器必须手动，而且不能混用

clearTimeout 只能清 setTimeout 返回的 ID，clearInterval 只能清 setInterval 的 ID。拿错函数清，完全无效，ID 还在后台跑。

常见翻车现场：

• 组件卸载（Vue beforeUnmount / React useEffect cleanup）没清定时器 → 内存泄漏 + 回调里访问已销毁的 this 或 ref 报错
• 多个 setTimeout 共用一个变量（如 let timer = null），后设的覆盖前设的，导致前一个再也清不掉
• 把 setInterval 的 ID 传给 clearTimeout —— 看似没报错，实则白清

最保险的习惯：每次设定时器，都单独声明变量存 ID；清理时先判空再清，并置为 null。

实际开发中，多数重复任务用 setTimeout 递归比 setInterval 更可靠；而真正需要“不管怎样都准时触发”的场景极少——那通常该交给 Web Workers 或服务端定时任务。