使用 setInterval 需保存定时器 ID 以便 clearInterval 清理，避免内存泄漏；回调出错不会自动停止，需 try-catch；执行超时会导致任务堆积，推荐用递归 setTimeout 替代。
setInterval 怎么用：别只写个函数就跑
直接调用 setInterval 很简单，但真正在项目里用稳，得注意三件事：
- 必须保存返回的定时器 ID，否则没法停——漏掉
clearInterval就等于埋内存泄漏 -
回调函数里如果出错（比如访问了已销毁的 DOM 元素），
setInterval不会停，错误只打在控制台，后续照常触发 - 如果回调执行时间 > 设定间隔（比如
setInterval(fn, 1000)，但fn耗时 1200ms），下一次不会跳过，而是“立刻补上”，造成连发、节奏崩坏
正确启动 + 安全清理的写法：
const timerId = setInterval(() => {
try {
updateClock(); // 假设这是个可能失败的操作
} catch (err) {
console.error("clock update failed:", err);
}
}, 1000);
// 后续某处需要停掉（比如组件卸载、页面切换）
clearInterval(timerId);
setTimeout 和 setInterval 的本质区别不在语法，而在调度模型
setTimeout 注册的是一个「单次延迟任务」：到点执行一次，自动销毁；setInterval 启动的是一个「周期性调度器」：只要不手动停，它就按固定毫秒数不断尝试入队——不管上一轮有没有跑完、有没有报错。
-
setTimeout返回的 ID 只能用clearTimeout清除，混用clearInterval无效 -
setInterval的回调一旦开始执行，就和定时器本身解耦了；它不等你执行完，到点就塞新任务进宏任务队列 - 两者都支持传参：
setTimeout(fn, 1000, "a", "b")，但字符串形式（如setTimeout("alert(1)", 1000)）已废弃，不安全且无法捕获异常
为什么推荐用 setTimeout 递归替代 setInterval 做轮询
真实业务中，比如轮询接口状态、维持 WebSocket 心跳、刷新倒计时，用 setInterval 容易失控。更稳的做法是用 setTimeout 自调用：
立即学习“Java免费学习笔记（深入）”；
let pollId = null;
function poll() {
fetch("/api/status")
.then(res => res.json())
.then(data => {
renderStatus(data);
// 成功后再等 3 秒发起下一次
pollId = setTimeout(poll, 3000);
})
.catch(err => {
console.warn("poll failed, retry in 5s", err);
pollId = setTimeout(poll, 5000); // 失败可降频
});
}
pollId = setTimeout(poll, 3000); // 启动
- 每次都是上一轮完全结束（成功或失败）后才开始计时，节奏可控
- 可以动态调整下次延迟（比如失败后加长间隔），
setInterval固定死的间隔做不到 - 避免因网络慢、渲染卡顿导致任务堆积，尤其在低端设备或复杂页面中明显
容易被忽略的关键细节
很多人以为设成 0 就是“立刻执行”，其实不是：setTimeout(fn, 0) 和 setInterval(fn, 0) 都只是“尽快执行”，它们进的是宏任务队列，必须等当前同步代码和所有微任务跑完才轮到。
-
setInterval不适合做精准倒计时（比如毫秒级精度要求），建议用Date.now()算差值 +requestAnimationFrame或递归setTimeout - 清除定时器的时机很重要：React 组件中应在
useEffect的 cleanup 函数里清除；Vue 中在onBeforeUnmount；纯 JS 页面要在离开前或 DOM 销毁后及时清 - 同一个定时器 ID 不能重复清除，
clearInterval对已清除的 ID 无副作用，但也不报错——所以别靠“多清几次”来保险
