clearinterval 和 cleartimeout 各自对应 setinterval 和 settimeout 创建的定时器，混用无效且易埋隐患；清除前应判断 id 有效性并置 null，统一在生命周期钩子中清理，避免跨上下文复用或双重保险式错误调用。
clearInterval 和 clearTimeout 各管各的：前者只负责停掉 setInterval 启动的循环任务，后者只负责取消 setTimeout 设置的单次延迟任务。混用不仅无效，还容易埋下隐患。
区分定时器类型再选清除函数
关键不是“哪个函数更高级”，而是“它对应哪个定时器”。你调用 setInterval 得到的 ID，只能交给 clearInterval；setTimeout 返回的 ID，只能传给 clearTimeout。
- setInterval 返回的 ID 传给 clearTimeout → 定时器照常运行，无报错，但逻辑已失控
- setTimeout 返回的 ID 传给 clearInterval → 同样静默失败，任务不会被取消
- 传入 null、0 或已清过的 ID → 不报错，也不起作用，属于安全但无效操作
清除前建议做状态判断
避免重复清除或误清除，推荐在清除前检查 ID 是否有效，并清除后置为 null，方便后续判断。
- 把定时器 ID 存在组件实例、ref 或模块级变量中，别只放在局部作用域里
- 清除前加一层判断：if (this.timerId != null) { clearTimeout(this.timerId); this.timerId = null; }
- 在 React 的 useEffect 清理函数、Vue 的 beforeUnmount 或页面卸载事件中统一执行清除
注意运行上下文和热更新场景
定时器 ID 是上下文相关的，不能跨环境传递或复用。
- 主线程、Web Worker、Service Worker 中的定时器 ID 互不通用
- Service Worker 中 setInterval 可能被浏览器自动终止，此时 clearTimeout 可能失效
- Vite 等工具热更新时，若定时器定义在模块顶层，旧实例未清理会持续累积 → 必须监听 HMR 更新并主动清除
别用“双重保险”写法
比如先 clearTimeout 再 clearInterval，或者反过来——这不是保险，是逻辑混乱的信号。
- 真正该做的是厘清定时器来源：是 setTimeout 还是 setInterval？从哪来就用哪个清除
- 错误地写了 clearTimeout 却没生效，再补一句 clearInterval，掩盖了原始问题
- 某些老版 Safari 或 Electron 中，对无效 ID 多次调用清除函数可能引发静默内存残留
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
