setTimeout只执行一次，适合防抖、按钮禁用等场景；需递归调用才能实现循环；setInterval会持续执行直至手动清除，易因回调耗时导致堆积和内存泄漏；推荐用递归setTimeout替代setInterval以保障节奏稳定和生命周期可控。
setTimeout 只执行一次，别指望它自动循环
你写 setTimeout(fn, 1000)，就是告诉浏览器：“1 秒后调用 fn 一次，之后就没了”。它不会自己续费，也不会管你有没有清掉——它执行完就自动释放资源。
- 适合场景：防抖（用户停输 300ms 后搜）、按钮点击后禁用 1 秒、页面加载完延迟弹窗
- 支持直接传参：
setTimeout(console.log, 500, "hello", "world")，比setTimeout(() => console.log("hello", "world"), 500)更干净 - 设成 0 不等于“立刻执行”，只是尽快塞进宏任务队列，得等当前同步代码跑完
- 如果想模拟循环，必须手动递归：
function tick() { doWork(); setTimeout(tick, 1000); }—— 这才是可控节奏的起点
setInterval 会一直跑，直到你亲手叫停
setInterval(fn, 1000) 的意思是：“从现在起，每 1 秒就尝试调用 fn 一次”，它不看上一次是否结束、有没有报错、甚至页面是否还活着。
- 常见错误现象：倒计时从 “5→4→3” 突然跳成 “5→2→0”，或控制台疯狂打印日志，页面卡顿
- 根本原因：如果
fn执行耗时 > 1000ms（比如请求慢、渲染重），浏览器会把后续调用“堆进队列”，等前一个结束立刻连发，造成节奏崩坏 - 它不会自动停止，漏掉
clearInterval(id)就是内存泄漏：回调函数 + 闭包引用的对象全被锁住，组件卸载了还在后台发请求 - 清除必须配对：
clearInterval()只能清setInterval()返回的 ID，拿clearTimeout()去清会完全无效
为什么推荐用递归 setTimeout 替代 setInterval？
不是为了炫技，而是为了解决真实问题：时间漂移、回调堆积、难以调试。
- 递归
setTimeout天然保证“上一次执行完，才开始算下一次延时”，节奏稳定，不怕回调变慢 - 错误只影响当次，不会让整个轮询链崩掉；而
setInterval回调里抛错，定时器照常触发，错误被吞掉，只剩控制台一行警告 - 更易控制生命周期：启动和清除都在同一作用域，React 的
useEffectcleanup 里写clearTimeout(timerId)就够了，不用额外存 ref - 示例：
let timerId = null;<br>function poll() {<br> fetch("/api/status").then(r => r.json()).then(data => {<br> updateUI(data);<br> });<br> timerId = setTimeout(poll, 3000); // 成功/失败后都重新计时<br>}<br>timerId = setTimeout(poll, 3000);
清除定时器时最容易忽略的三个细节
90% 的内存泄漏和重复执行 bug，都出在这几步。
立即学习“Java免费学习笔记（深入）”；
- 清除函数必须和创建函数严格对应：
clearTimeout()清setTimeout()的返回值，clearInterval()清setInterval()的返回值，混用=白清 - ID 必须保留引用：在函数外声明变量保存 ID，不能在闭包里重新声明同名变量覆盖旧 ID
- 组件卸载/页面跳转前必须清：React 中
useEffect的 cleanup 函数、Vue 的onBeforeUnmount、原生beforeunload事件里都要检查并清除
setTimeout。那个看似省事的 setInterval，往往在压力测试或弱网环境下第一个暴露问题。 
