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 递归：
立即学习“Java免费学习笔记（深入）”；
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/ ReactuseEffect cleanup）没清定时器 → 内存泄漏 + 回调里访问已销毁的this或ref报错 - 多个
setTimeout共用一个变量（如let timer = null），后设的覆盖前设的，导致前一个再也清不掉 - 把
setInterval的 ID 传给clearTimeout—— 看似没报错，实则白清
最保险的习惯：每次设定时器，都单独声明变量存 ID；清理时先判空再清，并置为 null。
setTimeout 递归比 setInterval 更可靠；而真正需要“不管怎样都准时触发”的场景极少——那通常该交给 Web Workers 或服务端定时任务。 
