javascript定时器与浏览器重绘不直接联动，二者虽独立计时但共用主线程；定时器回调需等待js栈清空及下一次渲染帧才生效，而requestanimationframe天然嵌入渲染流程，更精准高效。
JavaScript 定时器（setTimeout、setInterval）和浏览器重绘不是直接联动的，它们各自运行在不同线程、遵循不同节奏，但最终都挤在主线程上执行，因此实际效果高度依赖两者如何“错峰”或“对齐”。
定时器不控制重绘，只排队等空闲
定时器由独立线程计时，到点后把回调推入宏任务队列；但它不能强制浏览器立刻重绘。回调真正执行，必须等：
- JS 执行栈完全清空（包括所有同步代码和本轮微任务）
- 浏览器进入一次渲染检查周期——若 DOM 有变更且距上一帧未超 16.6ms（60Hz），才 layout → paint
也就是说，哪怕你 setTimeout(() => el.style.left = '100px', 0)，样式改了，画面也不会马上动；要等到下一次渲染帧才生效。
GUI 渲染线程与 JS 线程互斥
浏览器中，JS 引擎线程和 GUI 渲染线程不能同时运行：
- JS 正在跑长任务时，渲染线程被挂起，页面“卡住”，无法重排或重绘
- 所有 DOM 修改、样式变更只是“记账”，真正绘制得等 JS 让出主线程
- 连续多次定时器修改同一元素位置，可能被合并成一次重排，也可能因 JS 占用过久导致掉帧
requestAnimationFrame 是天然桥梁
requestAnimationFrame 不是定时器，而是浏览器在每帧绘制前主动发出的“干活邀请”：
- 它嵌入渲染流水线，在样式计算之后、布局之前执行，确保动画更新不触发强制回流
- 自动匹配屏幕刷新率（60Hz/120Hz），页面不可见时暂停，切回时恢复并提供精确时间戳
- 比
setTimeout(..., 16)可靠得多——后者受宏任务排队延迟影响，实际间隔可能飘到 30ms+，造成跳帧
用时间差模拟周期逻辑，兼顾 RAF 和业务需求
如果业务需要“每 500ms 检查一次状态”，又想保持与渲染同步，不要用 setInterval，而该用 RAF 驱动的时间校准：
- 记录上一次执行的
performance.now()时间戳 - 每次 RAF 回调里计算差值，≥500ms 才执行逻辑，并更新时间戳
- 这样既避免回调堆积，也不丢任务，还能随页面可见性自动节流
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
