setTimeout(fn, 0) 并非立刻执行，而是将回调推入宏任务队列，需等待当前宏任务结束、所有微任务清空后执行，受浏览器最小延迟限制（嵌套≥6层时强制≥4ms）及系统负载影响。
setTimeout(fn, 0) 并不意味着“立刻执行”，而是将回调函数推入任务队列，等待当前调用栈清空且主线程空闲时执行。实际延迟通常在 1–4 毫秒之间，受浏览器调度机制、系统负载和嵌套调用深度影响，并非精确的 0ms。
浏览器最小延迟限制
根据 HTML 标准，当嵌套层级 ≥ 6 时，setTimeout 的最小延迟会被强制设为 4ms（早期 Chrome 和 Firefox 实现），即使传入 0 或 1。这是为防止过度抢占主线程、保障页面响应性而设的硬性节流机制。
- 前 5 次 setTimeout(0) 可能快速连续触发（如 0.1–1ms 偏差）
- 第 6 次及之后，浏览器会自动拉长至 ≥4ms，实际常为 4–6ms
- 可通过递归调用计数验证：每调用一次 setTimeout 就累加层级，观察时间戳差值突变点
事件循环与执行时机
零延迟只表示“尽快安排”，不跳过事件循环阶段。回调必须等到以下条件全部满足后才执行：
- 当前宏任务（如 JS 主线程代码、事件处理函数）完全执行完毕
- 所有微任务（Promise.then、queueMicrotask）已清空
- 渲染帧尚未提交（若在 requestAnimationFrame 后立即 setTimeout(0)，它将在下一帧前执行，但仍在当前宏任务之后）
因此，在密集计算或长任务中，setTimeout(0) 的实际延迟可能达几十毫秒甚至更久。
立即学习“Java免费学习笔记（深入）”；
与 Promise.then 的关键区别
两者常被拿来对比，但本质不同：
- setTimeout(0) 是宏任务，插入任务队列尾部，至少要等一轮事件循环
- Promise.then() 是微任务，插入微任务队列，在当前宏任务结束后、渲染前立即执行
- 同一段代码中，Promise.then 总比 setTimeout(0) 先执行，偏差常达 0.1ms 级别
例如：console.log(1); Promise.resolve().then(() => console.log(2)); setTimeout(() => console.log(3), 0); console.log(4); 输出顺序必为 1 → 4 → 2 → 3。
实用建议与替代方案
不要依赖 setTimeout(0) 实现“同步转异步”的精确时序，尤其在性能敏感或动画逻辑中：
- 需确保 DOM 更新后操作？用 queueMicrotask() 更轻量、更及时
- 需对齐浏览器渲染帧？优先选 requestAnimationFrame()，而非 setTimeout(0)
- 需绕过最小延迟限制？可改用 performance.now() 替代 Date.now()，获取更高精度时间戳
