setTimeout 执行时间常长于设定值，因其仅保证“至少延迟”，实际受任务队列、主线程空闲及前序任务耗时影响；应结合 performance.now() 校准、优先选用 requestAnimationFrame 或 Web Workers 实现精准控制。
setTimeout 的执行时间常常比设定值长，这不是 bug，而是 JavaScript 运行机制决定的——它只保证“至少延迟这么久”，不保证“精确在这一刻执行”。真正影响执行时机的，是任务队列状态、主线程是否空闲、以及之前任务的耗时。
理解 setTimeout 延迟偏大的根本原因
JavaScript 是单线程的，所有定时器回调都得排队等主线程空闲。如果 setTimout 设置为 100ms，但此时主线程正执行一个耗时 200ms 的同步任务（比如大量计算或 DOM 操作），那回调实际会在 300ms 后才执行。
- 定时器触发后，回调进入宏任务队列，必须等当前调用栈清空 + 当前任务执行完才能执行
- 页面卡顿、频繁重排重绘、长任务（Long Task）都会挤压定时器执行时机
- 浏览器节流策略：标签页非激活状态时，setTimeout 最小间隔会被限制为 1000ms 左右
用 performance.now() 动态校准执行时机
当需要相对精准的时间控制（比如动画、倒计时、节拍同步），不能依赖 setTimeout 的 delay 参数，而应记录起始时间，在回调中用 performance.now() 判断真实经过时间，并决定是否立即执行、跳过、或重新调度。
例如实现一个误差可控的周期性任务：
立即学习“Java免费学习笔记（深入）”；
function accurateInterval(callback, interval) {
let startTime = performance.now();
function tick() {
const elapsed = performance.now() - startTime;
if (elapsed >= interval) {
callback();
startTime += interval; // 对齐理论时间点
}
requestAnimationFrame(tick); // 用 RAF 避免被节流
}
tick();
}替代方案：优先考虑 requestAnimationFrame 或 Web Workers
对视觉相关操作（如动画、UI 更新），requestAnimationFrame 是更合适的选择——它天然与屏幕刷新率同步，不会出现“掉帧式延迟”；对计算密集型延时逻辑，可把耗时部分移到 Web Worker 中，避免阻塞主线程导致 setTimeout 失效。
- 动画/渲染类逻辑：用 requestAnimationFrame 替代 setTimeout，再配合时间差做插值
- 后台计时或复杂逻辑：用 Worker 执行倒计时或状态检查，通过 postMessage 通知主线程
- 高精度需求场景（如音频同步）：改用 Web Audio API 的 audioContext.currentTime
避免常见陷阱：嵌套 setTimeout 与 clearTimeout 配合不当
用 setTimeout 模拟 setInterval 时，若未正确清理旧定时器，或在异步回调里重复设置新定时器，容易造成“定时器堆积”，让后续执行越来越滞后。
安全写法示例：
let timerId = null;
function startLoop() {
if (timerId !== null) clearTimeout(timerId);
const start = performance.now();
timerId = setTimeout(() => {
doWork();
// 下次调度基于实际耗时动态调整
const elapsed = performance.now() - start;
const nextDelay = Math.max(0, 100 - elapsed); // 补偿已耗时间
timerId = setTimeout(startLoop, nextDelay);
}, 100);
}不复杂但容易忽略
