javascript定时器如何工作_setTimeout和setInterval有什么区别【教程】

setTimeout只执行一次，setInterval持续重复触发；前者任务完成即销毁，后者不等前次结束就按周期调度，易导致回调堆积、错误静默、内存泄漏，推荐用递归setTimeout实现轮询。

setTimeout 只执行一次，setInterval 会“不管不顾”地重复触发

核心区别不在语法，而在执行模型：setTimeout 注册一个单次延迟任务，到点执行完就自动销毁；setInterval 启动一个周期性调度器，只要你不手动停，它就会按间隔不断尝试触发回调——哪怕上一次还没跑完。

• 如果 setInterval(fn, 1000) 中的 fn 平均耗时 1200ms，浏览器不会跳过下一次，而是立刻补上，导致回调堆积、日志狂刷、倒计时跳帧（比如 “5→3→1”）
• setTimeout 抛错只影响这一次；setInterval 回调一旦出错，错误会被吞掉，定时器照常运行，后续仍不断入队
• 两者返回的 ID 都是数字，但必须配对清除：clearTimeout(id) 只能清 setTimeout 的，clearInterval(id) 只能清 setInterval 的，混用完全无效

绝大多数轮询/心跳场景，该用递归 setTimeout，而不是 setInterval

真实项目里，API 轮询、websocket 心跳、状态检测等，都推荐用 setTimeout 递归实现。这不是“多写两行”，而是避免节奏失控的根本解法。

• 递归写法确保「上一次执行彻底结束，才开始算下一轮延时」，节奏稳定，不怕回调变慢
• 示例：

  function poll() {   fetch('/api/status')     .then(res => res.json())     .then(data => console.log(data))     .finally(() => setTimeout(poll, 3000)); } poll();

• 对比 setInterval：若某次请求卡住 4 秒，递归版只是下次延后 3 秒执行；而 setInterval 会在第 3 秒、第 4 秒、第 5 秒连续触发，可能瞬间发 3 个请求

传参和错误兜底，别踩字符串陷阱和静默失败

老式写法 setTimeout("doSomething()", 1000) 已废弃，它走 eval，不安全、无法捕获闭包变量、调试困难，且错误无法被外层 try/catch 捕获。

• 现代写法统一用函数引用 + 后续参数：setTimeout(console.log, 1000, "hello", "world") 或 setTimeout(() => doSomething(a, b), 1000)
• setInterval 回调必须自己包 try/catch，否则异常被吞，你根本不知道它早崩了
• 即使设 delay 为 0，两者也都进宏任务队列，得等当前同步代码跑完——不是“立刻执行”

清除定时器不是可选项，而是内存泄漏的开关

没清除的定时器，它的回调函数和所有闭包引用的对象就一直活在内存里。尤其在 react/vue 单页应用中，组件卸载了但 setInterval 还在跑，轻则重复请求，重则页面卡死。

立即学习“Java免费学习笔记（深入）”；

• React useEffect 中启用定时器，必须在 cleanup 函数里调用 clearInterval 或 clearTimeout
• 上线前建议加一句 console.warn("interval still running!") 做兜底提醒
• 页面关闭时未清除的定时器，仍会持续占用资源，直到进程终止

真正难的不是写对语法，而是判断「这个逻辑到底需不需要严格守时」「它会不会阻塞」「它生命周期归谁管」——这些才是定时器出问题的根源。