定时器回调耗时过长会导致系统性延迟、状态错乱与资源浪费；setInterval严格串行执行且不补漏，异常不中断但致逻辑失效；推荐用setTimeout递归替代以提升可控性。

定时器回调执行耗时过长，会直接拖慢后续所有依赖时间的逻辑——不是“偶尔不准”，而是系统性延迟、状态错乱甚至资源浪费。

实际执行间隔被拉长，周期任务失去节奏

setInterval 不会因为前一次回调没跑完就跳过或并发执行。它严格串行：当前回调彻底结束，才把下一次回调推入任务队列。

• 设间隔为 500ms，但回调平均耗时 800ms → 实际两次执行间隔约 800ms，不是 500ms
• 错过的周期不会“补上”，也不会堆积，直接丢弃
• 看起来是“变慢了”，本质是定时器在等主线程腾出手来

异常不会中断定时器，但会让逻辑静默失效

如果回调里抛出未捕获错误，setInterval 本身继续运行，但后续每次执行都可能重复失败。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• DOM 元素已被移除，却还在尝试更新 → 持续报错，UI 不更新也不提示
• 计数器变量没递增、开关标志没翻转 → 状态停滞，行为不可预测
• 错误被吞掉，开发者很难察觉任务早已“空转”

主线程被占满，整个页面响应停摆

一个耗时 2s 的同步循环，会让所有定时器、点击事件、动画帧全部卡住，直到它完成。

立即学习“Java免费学习笔记（深入）”；

• 不是定时器坏了，是 JavaScript 引擎根本没机会处理新任务
• 浏览器可能弹出“脚本无响应”，用户无法交互
• requestAnimationFrame、fetch 回调、Promise.then 都得排队等

更可控的替代方案：用 setTimeout 递归代替 setInterval

每次回调执行完，再手动安排下一次，天然规避堆积和错位。

• 即使某次执行超时，下一次触发时间仍基于“这次结束时刻”计算
• 便于在中间加判断：比如数据已加载完成，就不再继续轮询
• 异常发生后，不主动重设，任务自然终止，避免静默循环