JavaScript定时器本身资源消耗低，但设计不当会引发主线程阻塞、延迟累积、内存泄漏、渲染压力、进程退出异常及24.8天上限误触发等系统性性能问题。
JavaScript 定时器本身不直接消耗大量资源，但其执行逻辑若设计不当，会在长期运行中持续拖累性能——这不是偶发卡顿，而是可累积、可放大的系统性损耗。
主线程阻塞会放大定时器延迟偏差
定时器回调属于宏任务，必须等当前调用栈清空、所有微任务执行完才能触发。如果页面存在长任务（如复杂计算、未分片的 DOM 批量操作），每次定时器都会被推迟，且偏差会随时间叠加：
- 设 setInterval(100ms)，但每次回调耗时 60ms → 实际间隔变成约 160ms，下一轮又从新起点延迟
- 连续 10 次执行后，整体节奏已漂移超 600ms，倒计时、节拍同步类功能开始明显失准
- 浏览器后台标签页还会进一步节流：setInterval 可能被降频至 1000ms 甚至更慢，用户切回页面时出现“跳帧”或批量触发
未清理的定时器是静默内存泄漏源
定时器 ID 是引用，只要没调用 clearTimeout/clearInterval，回调函数及其闭包内所有变量就无法被垃圾回收：
- 一个绑定了组件 state 的 setInterval，若组件卸载未清除，state 对象持续驻留内存
- 多个页面级轮询定时器长期存活，可能持有 DOM 节点、API 响应数据、大型数组等重型对象
- Node.js 环境中更危险：未清除的 setTimeout 会阻止进程优雅退出，成为 zombie timer
高频小间隔定时器触发渲染压力
低于 16ms 的 setInterval（如 10ms）并不带来更高精度，反而制造无效重绘和布局抖动：
立即学习“Java免费学习笔记（深入）”；
- 浏览器每帧仅刷新一次（60fps ≈ 16.7ms），10ms 定时器每帧执行多次，90% 的样式/布局计算被丢弃
- 频繁修改 offsetWidth、clientHeight 等触发强制同步布局，CPU 时间集中在 reflow 上
- 移动端尤其敏感：高频率 JS 执行加速电池消耗，iOS Safari 会主动 throttle 或暂停不可见 tab 的定时器
24.8 天上限导致长期任务失效风险
setTimeout 最大延时为 2147483647 毫秒（≈24.8 天），超限后行为是立即执行而非报错：
- 会员到期提醒、合同自动续期、数据归档等业务场景若硬编码 30 天 delay，上线即误触发
- 该问题在测试环境难暴露（短期运行正常），上线数周后才集中爆发，属典型“时间炸弹”
- 正确做法是拆解为链式 setTimeout：delay 24 天 → 回调中再设剩余天数的定时器
不复杂但容易忽略。
