定时器跳帧本质是回调执行严重偏离预期，因js单线程与事件循环机制导致宏任务排队延迟；根本原因包括长任务阻塞、微任务抢占、浏览器最小延迟限制及系统负载影响。
定时器跳帧，本质不是“丢帧”，而是回调执行时间严重偏离预期，导致视觉或逻辑上出现“断层”。根本原因在于 JavaScript 的单线程特性与事件循环的排队机制——定时器注册后，并不直接控制执行时机，而是被推入宏任务队列，必须等待当前同步任务、所有微任务执行完毕，且轮到它时主线程空闲，才能被执行。
定时器不是实时调度器，而是“排队预约”
setTimeout 和 setInterval 都属于宏任务。它们在设定时间点“到期”后，只是被标记为“可执行”，然后进入任务队列等待调度。如果此时主线程正忙于长任务（如复杂计算、大量 DOM 操作、未优化的渲染逻辑），该回调就会一直排队，直到前面所有任务清空。
- 例如：设置 setInterval(fn, 16ms) 模拟 60fps 动画，但某次 fn 执行耗时 40ms，那么下一次 fn 就会延迟至少 40ms 才能开始排队，实际间隔变成 56ms+，视觉上就“跳了一帧”
- 更关键的是，setInterval 不会跳过未执行的周期——如果连续三次都因阻塞没执行，它不会累积触发三次，而是等主线程空闲后只执行最新一次（或按实现略有差异），造成节奏紊乱
微任务抢占进一步加剧延迟感知
Promise.then、queueMicrotask 等微任务具有更高优先级，会在每个宏任务结束后立即全部执行。这意味着即使 setTimeout 到期了，只要前一个宏任务后面跟着一串微任务，它的回调仍需等待这些微任务全部跑完。
- 典型场景：在某个点击事件处理函数中发起多个 Promise 请求，再设一个 0ms setTimeout；这个 setTimeout 一定排在所有 Promise 回调之后，哪怕它写在 Promise 之前
- 这种“看不见的排队”让用户感觉“明明设了 0，怎么还卡一下才动”，其实是微任务队列在“插队”
浏览器最小延迟与系统负载双重限制
浏览器对 setTimeout 的 delay 参数有硬性下限：Chrome/Edge 实际最小延迟约 4ms（空闲时），后台标签页甚至升至 1000ms；而 setInterval 在页面非活跃状态下也会被大幅节流。此外，CPU 占用过高、内存压力大时，事件循环整体变慢，所有宏任务响应都会拉长。
- 开发中若依赖精确间隔（如音频同步、游戏逻辑），不能靠 setInterval 硬扛，应改用 requestAnimationFrame（与屏幕刷新强绑定）或链式 setTimeout（每次在回调里重设，避免累积误差）
- 可通过 performance.now() 在回调内记录实际执行时间戳，对比计划时间，量化跳帧程度，用于性能诊断
如何缓解跳帧问题
核心思路是减少主线程阻塞、避免依赖固定间隔、主动管理执行节奏。
- 将长任务拆分为多个小任务，用 queueMicrotask 或 setTimeout(..., 0) 分片执行，给事件循环喘息机会
- 动画类逻辑优先使用 requestAnimationFrame，它由浏览器统一调度，天然对齐刷新率，且在页面不可见时自动暂停
- 需要稳定周期逻辑时，放弃 setInterval，采用“执行完立刻预约下一次”的链式 setTimeout，并在每次回调中根据上一次执行时间动态计算 delay，补偿已发生的延迟
- 对非关键定时任务（如日志上报、状态轮询），启用节流或降频策略，在页面失焦或低电量时主动让步
