17370845950

setTimeout只执行一次，适合防抖、延迟初始化等单次调度；setInterval重复执行但易导致时间不准、回调堆积、内存泄漏，需显式清除，精准轮询推荐用递归setTimeout实现。

setTimeout 只执行一次，setInterval 会重复执行——这是最本质的区别。但光记这点不够，实际写代码时，选错或用错会导致倒计时不准、请求堆积、内存泄漏甚至页面卡死。

什么时候该用 setTimeout？防抖、延迟初始化、单次异步调度

它适合“等一会儿再干一次”的场景，比如用户停止输入 300ms 后才发起搜索建议请求（防抖），或者页面加载完 1 秒再显示欢迎弹窗。

• 回调只触发一次，无需手动清理（除非你想提前取消）
• 支持直接传参：setTimeout(greet, 1000, 'Alice', 25)，比包装函数更干净
• 即使设为 0，也不会立即执行，而是插入到任务队列末尾，让出主线程给当前同步任务
• 若想循环执行，必须在回调里再次调用 setTimeout（递归式），这样能避免执行堆积

为什么 setInterval 容易出问题？时间不准 + 回调堆积

它按固定间隔「尝试」触发回调，但不保证准时。如果某次回调执行耗时 > 间隔时间（比如接口响应慢了 1.2s，而间隔设的是 1s），下一次回调不会被跳过，而是立刻执行，造成连续触发甚至雪崩。

• 不会因前一次未结束就跳过下一次，容易引发竞态或重复提交
• 错误不会中断定时器：哪怕回调抛错，setInterval 仍继续运行
• 必须用 clearInterval(id) 显式清除，否则页面关闭前一直占内存（尤其在 SPA 中组件卸载时极易漏清）
• 真正需要“精准间隔”的轮询（如心跳检测），推荐用 setTimeout 递归实现

清除定时器不是可选项，是必做动作

没清的 setInterval 是前端内存泄漏的常见元凶；没清的 setTimeout 虽然只执行一次，但在组件销毁后执行回调（比如更新已卸载组件的 state），会报 React 的 Can't perform a React state update on an unmounted component 类错误。

• 保存 ID 很关键：const timerId = setTimeout(...)，后续才能清除
• React 中，useEffect 清理函数里必须调用 clearTimeout(timerId) 或 clearInterval(timerId)
• 不要用字符串形式传回调（如 setTimeout('doSomething()', 1000)），既不安全又无法清除（ID 对不上）

function startCountdown() {
  let count = 5;
  const timerId = setInterval(() => {
    console.log(count--);
    if (count < 0) clearInterval(timerId); // 必须主动终止
  }, 1000);
}

// 更健壮的写法（避免堆积）：
function startCountdownSafe() {
  let count = 5;
  function tick() {
    console.log(count--);
    if (count >= 0) setTimeout(tick, 1000); // 下次由 setTimeout 控制时机
  }
  setTimeout(tick, 1000);
}

真正难的不是“怎么设”，而是“什么时候停”和“为什么不能无脑用 setInterval”。尤其在异步操作不可控（网络、渲染阻塞）的环境下，靠间隔驱动的定时器天然不可靠。