setTimeout不保证精准延时，仅确保至少延迟后入队；实际执行受事件循环和主线程负载影响；requestAnimationFrame更准时且绑定刷新帧；微任务适合同步后立即执行且不阻塞渲染。
宏任务本身不提供“精准延时”，它只保证“至少延迟指定时间后入队”；真正影响执行时刻的是事件循环排队机制和主线程负载。所谓“精准”，是指在可预期、可复现的调度节奏中，让回调尽可能靠近目标时间点执行——这需要避开宏任务固有抖动，用更可控的调度策略替代或协同。
理解 setTimeout 的真实行为
setTimeout(fn, 100) 并非“100ms后执行fn”，而是“100ms后把fn推入宏任务队列”。实际执行时间 = 推入时间 + 前置宏任务耗时 + 所有微任务耗时 + 渲染开销。浏览器最小间隔约4ms（HTML5规范），且页面后台运行时可能节流至1000ms以上。因此，单纯依赖 setTimeout 无法实现亚毫秒或稳定±1ms级精度。
用 requestAnimationFrame 对齐渲染帧
对动画、UI同步类延时，优先用 requestAnimationFrame 替代 setTimeout：它天然绑定浏览器刷新节奏（通常60fps → 每16.6ms一帧），执行时机比 setTimeout(0) 更准时、无竞态，且不会被节流。
- 适合场景：滚动跟随、动画起始控制、DOM状态与视觉帧对齐
- 示例：想“在下一帧更新样式”，不用 setTimeout(() => el.style.opacity = 1, 0)，直接用 requestAnimationFrame(() => el.style.opacity = 1)
用微任务填补调度空隙
当需要“同步代码结束后立刻执行，但又不能阻塞渲染”，用 Promise.then 或 queueMicrotask：它们属于微任务，在当前宏任务末尾、渲染前统一执行，延迟极低（通常
立即学习“Java免费学习笔记（深入）”；
- 适用情况：表单校验通过后立即启用按钮、响应式状态链式更新
- 注意：避免无限微任务循环，否则会卡死页面
高精度场景用 performance.now + 循环等待（仅限非主线程）
若必须达到微秒级控制（如音频同步、游戏逻辑帧对齐），可在 Web Worker 中使用 performance.now() 配合 while 循环“忙等”：
- 主线程严禁 busy-wait，会完全冻结交互
- Worker 中执行不阻塞UI，且 performance.now() 提供亚毫秒精度时间戳
- 示例：const start = performance.now(); while (performance.now() - start
监控与校准延迟偏差
用 PerformanceObserver 监听 longtask，再结合 setTimeout(fn, 0) 测量实际调度延迟：
- 记录 setTimeout(fn, 0) 被调用时刻 t1
- fn 执行时记录 t2，则 t2 − t1 即为本次事件循环延迟
- 持续收集该值，可判断是否需降级策略（如切到 requestIdleCallback 处理非关键任务）
