定时器回调耗时过长会导致系统性延迟、状态错乱与资源浪费；setinterval严格串行执行且不补漏，异常不中断但致逻辑失效；推荐用settimeout递归替代以提升可控性。
定时器回调执行耗时过长，会直接拖慢后续所有依赖时间的逻辑——不是“偶尔不准”，而是系统性延迟、状态错乱甚至资源浪费。
实际执行间隔被拉长，周期任务失去节奏
setInterval 不会因为前一次回调没跑完就跳过或并发执行。它严格串行：当前回调彻底结束，才把下一次回调推入任务队列。
- 设间隔为 500ms，但回调平均耗时 800ms → 实际两次执行间隔约 800ms，不是 500ms
- 错过的周期不会“补上”，也不会堆积，直接丢弃
- 看起来是“变慢了”，本质是定时器在等主线程腾出手来
异常不会中断定时器，但会让逻辑静默失效
如果回调里抛出未捕获错误，setInterval 本身继续运行，但后续每次执行都可能重复失败。
- DOM 元素已被移除，却还在尝试更新 → 持续报错，UI 不更新也不提示
- 计数器变量没递增、开关标志没翻转 → 状态停滞，行为不可预测
- 错误被吞掉，开发者很难察觉任务早已“空转”
主线程被占满，整个页面响应停摆
一个耗时 2s 的同步循环，会让所有定时器、点击事件、动画帧全部卡住，直到它完成。
- 不是定时器坏了，是 JavaScript 引擎根本没机会处理新任务
- 浏览器可能弹出“脚本无响应”，用户无法交互
- requestAnimationFrame、fetch 回调、Promise.then 都得排队等
更可控的替代方案：用 setTimeout 递归代替 setInterval
每次回调执行完，再手动安排下一次，天然规避堆积和错位。
- 即使某次执行超时，下一次触发时间仍基于“这次结束时刻”计算
- 便于在中间加判断：比如数据已加载完成，就不再继续轮询
- 异常发生后，不主动重设，任务自然终止，避免静默循环
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
