setTimeout 和 setInterval 的核心难点在于执行时机不可控、易致内存泄漏且需手动清理；应优先用 Promise 封装 delay、requestAnimationFrame 或递归 setTimeout 替代。
setTimeout 和 setInterval 不是“要学”的知识点，而是“要用就查、用错就崩”的工具——它们的坑不在语法，而在执行时机、内存泄漏和清理逻辑。
setTimeout 为什么没按预期延迟执行？
常见现象：setTimeout 看似“延迟了”，但实际执行时间比设定值长很多，尤其在页面卡顿、标签页休眠或大量计算后。
-
浏览器对后台标签页会强制限制定时器精度（Chrome 下最低约 1000ms），
setTimeout(fn, 10)可能变成 1000ms 才触发 - JS 是单线程的，如果主线程正忙（比如长循环、同步 AJAX、大量 DOM 操作），
setTimeout的回调只能排队等，不会中断当前任务 - 传参错误：写成
setTimeout(fn(), 1000)是立即执行fn，应写成setTimeout(fn, 1000)或setTimeout(() => fn(), 1000)
setInterval 容易造成重复触发和内存泄漏
最典型问题：组件卸载了，setInterval 还在跑；或者状态更新后多次调用 setInterval，却没清除旧的句柄。
- 必须保存返回值（数字 ID），后续用
clearInterval主动清理：const id = setInterval(...); clearInterval(id); - React/Vue 等框架中，务必在
useEffect的 cleanup 函数或beforeUnmount钩子中清除，否则定时器持续引用组件实例，阻止 GC - 不要依赖
setInterval做精确倒计时——它不校准执行间隔。连续两次执行之间若耗时较长，下一次仍按“原定时刻”触发，可能堆积
替代 setTimeout/setInterval 的现代方案
当需要更可控、可取消、更符合异步语义的延迟行为时，原生 setTimeout 和 setInterval 往往不是最优解。
立即学习“Java免费学习笔记（深入）”；
- 用
Promise封装延迟：const delay = ms => new Promise(r => setTimeout(r, ms)); await delay(1000); - 需要重试逻辑？别套多层
setTimeout，改用带退避策略的递归 Promise - 动画类场景优先用
requestAnimationFrame；精确音频/游戏逻辑考虑Web Workers+performance.now()自行轮询 - 长期运行的轮询（如检查登录态），建议用“成功后再次
setTimeout”而非setInterval，避免失败堆积
真正难的不是怎么写 setTimeout(fn, 1000)，而是判断该不该用它、什么时候必须清除、以及它是否正在悄悄拖慢你的应用响应速度。
