17370845950

setTimeout只执行一次，setInterval会反复触发；前者用于单次延迟场景如防抖、延时提示，后者需手动清除且易因执行超时或异常导致回调堆积、内存泄漏。

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

这是最本质的区别：setTimeout 是“等一会儿干一次”，setInterval 是“每隔一会儿就干一次”。前者调用后自动结束；后者一旦启动，就会持续运行，直到你手动叫停。

• setTimeout 返回一个定时器 ID，可用 clearTimeout(id) 取消 —— 即使不取消，它也只执行一回，不会泄漏
• setInterval 同样返回 ID，但必须配对使用 clearInterval(id)，否则会一直跑，占用内存、触发多余逻辑，甚至导致页面卡顿
• 两者最小延迟都受浏览器限制（通常 ≥4ms），且实际执行时间不精确：主线程忙时，回调会被推迟到空闲时才进宏任务队列

什么时候该用 setTimeout，而不是 setInterval？

防抖、延时提示、模拟接口响应、初始化后延迟加载……这些都属于「单次延迟」场景，setTimeout 更自然、更安全。

• 用户在输入框连续打字，你想等他停 300ms 再发搜索请求 → 用 setTimeout + 每次输入前 clearTimeout 防抖
• 弹窗显示 2 秒后自动关闭 → setTimeout(() => hide(), 2000)，干净利落
• 页面加载完 1 秒再初始化某个模块 → setTimeout(init, 1000)，无需清理

setInterval 容易出问题的三个典型坑

setInterval 看似简单，但实际项目里翻车最多：不是忘了清除，就是执行不准，或者回调堆积。

• 不主动清除 → 内存泄漏 + 逻辑错乱：比如组件卸载了，定时器还在刷接口，可能更新已销毁的 state，报 Cannot update a component while rendering
• 回调执行时间 > 间隔时间 → 后续回调被挤压、连续触发：例如设了 se

  

  tInterval(fetchData, 1000)，但某次 fetchData 耗时 1500ms，下一次不会跳过，而是立刻执行，造成“连发”
• 错误未被捕获 → 定时器照常运行：哪怕回调里抛了异常，setInterval 不会停，下次还会来 —— 这会让问题更难定位

替代方案：需要稳定间隔时，优先用 setTimeout 递归调用：

function tick() {
  doSomething();
  setTimeout(tick, 1000); // 下次执行前才设新定时器
}
tick();

参数和行为细节差异不可忽略

语法看着像，但传参方式和执行时机有隐性差别：

• 两者都支持额外参数传给回调：setTimeout(cb, 1000, arg1, arg2)，比写匿名函数更干净
• setInterval 的回调如果执行出错（比如访问了 undefined 属性），错误会上抛，但定时器本身不停 —— 所以务必在回调里加 try/catch
• setTimeout 设置 0 毫秒，不代表立刻执行，只是“尽快”，它仍要排队等当前同步代码跑完
• 现代开发中，动画类重复任务应优先用 requestAnimationFrame，而非 setInterval；轮询类任务建议配合 AbortController 或状态判断做条件退出

真正麻烦的从来不是“怎么写”，而是“什么时候停”和“会不会堆”。尤其在 React/Vue 组件生命周期里，setInterval 忘关是最常见的定时器 bug 来源。