setTimeout延迟不准是因为它只保证最早执行时间，实际执行需等待任务队列清空和主线程空闲，可能被同步代码、微任务或高优先级宏任务阻塞。
setTimeout 的延迟时间为什么经常不准？
因为 setTimeout 只保证「最早在多少毫秒后执行」，不保证「正好在多少毫秒后执行」。它的回调必须等到当前任务队列清空、且主线程空闲时，才能被推入执行栈——这中间可能被其他同步代码、微任务或更高优先级的宏任务阻塞。
-
浏览器或 Node.js 的事件循环有明确的阶段划分（如 timers、pending callbacks、microtasks 等），
setTimeout属于 timers 阶段，但该阶段只有在上一轮循环结束、且满足时间阈值时才会触发 - 如果主线程正执行一个耗时 200ms 的
for循环，即使你设了setTimeout(fn, 10)，fn也要等那 200ms 跑完才可能执行 - 微任务（如
Promise.then）总在当前宏任务末尾立即执行，会进一步推迟下一轮 timers 阶段的开始时间
如何验证 setTimeout 被延迟？
用 performance.now() 记录真实触发时间差，比 Date.now() 更精确：
console.log('start:', performance.now());
setTimeout(() => {
console.log('timeout:', performance.now());
}, 10);
// 模拟阻塞
let now = performance.now();
while (performance.now() - now < 100) {
// busy wait
}
console.log('end:', performance.now());输出类似：start: 100.2end: 205.7timeout: 205.8
说明虽然设了 10ms，实际延迟了约 105ms。
setTimeout(0) 是立刻执行吗？
不是。它只是把回调插入「下一个 timers 阶段」的队列头部，仍需等待当前任务 + 所有微任务完成。常见误解是拿它代替 Promise.resolve().then()，但二者语义和时机不同：
-
setTimeout(fn, 0)→ 下一轮宏任务（可能被其他 timer/IO 回调插队） -
Promise.resolve().then(fn)→ 当前宏任务末尾，紧接在所有已排队微任务之后 - 在大量微任务场景下，
setTimeout(0)可能比Promise.then晚几十毫秒甚至更久
什么情况下 setTimeout 延迟会特别严重？
主要出现在以下场景：
立即学习“Java免费学习笔记（深入）”；
- 页面处于后台标签页时，浏览器会节流定时器（Chrome 通常限制为最小 1000ms），
setTimeout(fn, 10)可能变成 1000ms+ - Node.js 中若存在长时间同步计算（如大数组排序、正则回溯），会直接卡住整个事件循环
- 嵌套多层
setTimeout且未清理（比如忘记clearTimeout），导致任务积压、调度失序 - 使用
setInterval替代setTimeout做节流时，若回调执行时间 > 间隔，会形成“队列追赶”，延迟逐轮放大
真正需要精确节奏的逻辑（如动画、音频采样），别依赖 setTimeout，改用 requestAnimationFrame 或 Web Workers + performance.now() 自行校准。定时器不准不是 bug，是事件循环机制的必然表现。
