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!")做兜底提醒 - 页面关闭时未清除的定时器，仍会持续占用资源，直到进程终止
