定时器回调是事件循环调度工具，性能受执行时机、内容复杂度及与渲染/微任务/主线程阻塞的交互影响；应避免强制重排重绘、用 requestanimationframe 替代 settimeout 控制动画、批量修改样式、慎用 setinterval、移出耗时操作、合理搭配微任务优化响应链路。
定时器回调本身不直接处理异步事件响应，而是作为调度工具参与事件循环调度。真正影响性能的是回调执行时机、内容复杂度，以及它与渲染、微任务、主线程阻塞的交互关系。
避免在定时器回调中触发强制重排重绘
浏览器每帧约 16.7ms（60fps），若 setTimeout 回调中读写 DOM 属性（如 offsetHeight、getComputedStyle）或频繁修改样式，可能打断当前帧渲染流程，引发布局抖动（Layout Thrashing）。
- 把 DOM 读操作集中放在帧开头，写操作集中放在帧末尾
- 用 requestAnimationFrame 替代 setTimeout 控制动画类更新，它天然对齐渲染帧
- 批量修改样式：先修改 class，再通过 CSS 规则控制多属性，而非逐个设置 style.xxx
慎用 setInterval 处理高频响应逻辑
setInterval 不保证准时执行，尤其在页面失焦或主线程繁忙时，回调会积压并集中触发，造成响应突增和 CPU 峰值。
- 对轮询类逻辑（如心跳检测、状态轮询），优先用 setTimeout 递归调用 替代 setInterval
- 每次回调执行完再设下一次定时器，可自然规避积压，也便于动态调整间隔
- 若需精确节流（如限制用户输入处理频率），配合时间戳判断比单纯依赖 setInterval 更可靠
将耗时操作移出定时器回调栈
定时器回调属于宏任务，一旦其中包含同步计算、大数组遍历、JSON.parse 超长字符串等操作，会直接阻塞事件循环，延迟后续所有任务（包括用户点击、滚动、微任务）。
- 用 queueMicrotask 或 Promise.resolve().then() 把非关键逻辑“让出”主线程，留给微任务队列执行
- 对 CPU 密集型任务，考虑拆分为多个小块，用 setTimeout(..., 0) 分片执行，保持 UI 可响应
- 必要时使用 Web Worker 处理纯计算，完全隔离主线程
合理搭配微任务优化响应链路
定时器回调执行完毕后，事件循环会立即清空微任务队列。这个特性可用于“延后但尽快”执行 UI 更新或状态同步。
- 例如：在 setTimeout 中完成数据获取后，用 Promise.resolve().then(updateUI) 确保 UI 更新在当前宏任务结束后立刻执行，且早于下次渲染
- 避免在微任务中再嵌套 setTimeout —— 这会人为拉长任务链，削弱响应及时性
- 注意 Promise 链中的错误不会自动进入 catch，需显式 .catch() 或顶层 try/catch 包裹
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
