定时器必须及时清除，否则会导致内存泄漏和状态错乱；需严格区分 clearTimeout/clearInterval 的 ID 类型，组件卸载前务必清理，并优先使用 setTimeout 递归替代 setInterval。
定时器不清除，就等于在后台悄悄吃内存——尤其在单页应用里，组件反复挂载/卸载时，漏掉一次 clearTimeout 或 clearInterval，就可能堆积多个活跃定时器。
setTimeout 和 setInterval 的 ID 不能混用
这是最常被忽略、却不会报错的陷阱：clearTimeout 只能清除 setTimeout 返回的 ID，clearInterval 只能清除 setInterval 返回的 ID。传错 ID 不会报错，但定时器照常运行。
- 错误写法：
clearTimeout(intervalId)或clearInterval(timeoutId) - 正确做法：按创建方式严格对应——谁建的，谁清的
- 传入
null、0或已清除过的 ID，函数无反应，也不报错，容易掩盖逻辑错误
组件卸载前必须手动清理定时器
页面跳转、Modal 关闭、React 组件 unmount、Vue 组件 beforeUnmount —— 这些时机若不主动清除定时器，回调仍会执行，并尝试更新已销毁的 DOM 或 state，轻则报错，重则触发内存泄漏或状态错乱。
- React 函数组件推荐用
useEffect清理函数：useEffect(() => { const id = setInterval(fn, 1000); return () => clearInterval(id); }, []); - Vue 2 写在
beforeDestroy，Vue 3 写在onBeforeUnmount - 原生 JS 单页路由切换时，监听
popstate或手动维护生命周期钩子 - 清除后建议将 ID 设为
null或-1，后续可用if (id !== null)判断是否已清理
setInterval 容易堆积，优先考虑 setTimeout 递归
当回调执行时间 > 间隔时间（比如网络请求耗时 1500ms，但 setInterval 设为 1000ms），浏览器会排队执行，导致任务越积越多，UI 卡顿甚至崩溃。
立即学习“前端免费学习笔记（深入）”；
- 改用
setTimeout递归更可控：function poll() { fetch('/api').then(() => setTimeout(poll, 2000)); } poll(); - 每次执行完才决定是否发起下一次，天然避免堆积
- 调试时可直接在回调里打断点，堆栈清晰；而
setInterval的回调是系统自动触发，调用栈常为空 - 后台标签页中，
setInterval会被浏览器强制拉长到 ≥1000ms，setTimeout同样受影响，但递归方式至少保证“上一次完成后再等”，逻辑更健壮
清除定时器前先判断 ID 是否有效
重复调用 clearTimeout 或 clearInterval 虽不报错，但暴露了状态管理混乱——比如多次初始化定时器却没重置旧 ID，或者清理逻辑被多次触发。
- 典型风险场景：按钮多次点击触发
setInterval，但只存了一个intervalId变量 - 安全写法：
if (this.timerId != null) { clearTimeout(this.timerId); this.timerId = null; } - 避免把定时器 ID 声明在函数作用域内（如
const id = setTimeout(...)），应提升到组件实例属性、ref或模块级变量中，确保清理时能访问到最新值 - Vite/HMR 热更新时，顶层定义的定时器会不断新建，旧的未清理就会残留——务必在热更新钩子（如
import.meta.hot）中补上清理逻辑
真正难的不是写定时器，而是让它们准时来、准时走。ID 类型错、清理时机错、重复注册却不重置——这些问题往往不出现在控制台报错里，而是悄无声息地拖慢页面、耗尽内存、让倒计时不准、轮询发疯。
