定时器回调不阻塞主线程，但其内部同步代码会；应通过时间戳对比识别延迟，检查大循环、长任务等耗时操作，控制单次执行≤10ms，必要时分片或用web worker处理。
定时器回调本身不会阻塞主线程，但回调函数里写的同步代码会。真正影响执行及时性、造成“假卡顿”或任务堆积的，往往是回调内部的耗时操作。
观察回调是否被延迟执行
最直接的方式是加时间戳对比：
- 在 setTimeout/setInterval 启动前 记录
Date.now() - 在回调函数开头再次记录
Date.now() - 两者差值明显大于设定延迟（比如设 100ms，实际延迟 800ms），说明前面有同步任务拖住了主线程
识别回调内部的同步阻塞点
重点检查回调里是否包含以下典型同步耗时操作：
- 大型循环（如
for (let i = 0; i ） - 递归计算未做节流（如未优化的阶乘、斐波那契）
- 同步 DOM 操作 + 强制重排/重绘（如连续读写
offsetHeight、getComputedStyle） - 大量字符串拼接或正则匹配（尤其未编译的复杂正则）
用 Performance API 定位长任务
浏览器开发者工具的 Performance 面板能直观暴露问题：
- 录制一段含定时器运行的操作
- 查看 Flame Chart，找持续 > 50ms 的长任务（Long Task）
- 展开该任务，看是否包含你的回调函数及其内部同步逻辑
- 配合
console.time()在回调内分段打点，确认哪一段耗时异常
避免回调自身成为阻塞源
即使回调启动及时，执行太久也会挤占后续任务时间：
- 单次回调执行尽量控制在 10ms 内（保障 60fps 渲染帧率）
- 耗时逻辑拆成小块，用
setTimeout(..., 0)或queueMicrotask分片执行 - 考虑 Web Worker 处理纯计算型任务，完全脱离主线程
- 对重复高频回调（如
setInterval(fn, 16)），加节流或防抖判断是否真需执行
