setTimeout最小延迟为4ms是HTML规范强制约束的结果：当嵌套层级超过5层且timeout小于4ms时，浏览器必须将其提升至至少4ms，旨在防止主线程被高频定时器耗尽。
setTimeout 的最小延迟不是“不准”，而是被规范和实现共同约束的调度策略。它不承诺精确时间，只保证“至少等待”，而这个“至少”在多数场景下就是 4ms —— 但这并非铁律，而是条件触发的结果。
最小延迟 4ms 是怎么来的
HTML Living Standard 明确规定：当 setTimeout 的嵌套层级超过 5 层时，浏览器必须将延迟强制设为 ≥ 4ms。这不是 bug，是防滥用机制：
- 防止高频递归调用（如
setTimeout(fn, 0)连续嵌套）耗尽主线程资源 - 避免大量微秒级任务挤占渲染时机，导致页面卡顿或电池过热
- 非活动标签页中，该限制可能升至 1000ms，进一步降低后台页功耗
为什么有时测出远低于 4ms
现代浏览器（如 Chrome 138+）在特定条件下会绕过 4ms 限制：
- 顶层调用（嵌套层级 ≤ 5）、页面处于激活状态、主线程空闲时，实际延迟可低至 0.1ms
- 这依赖底层调度器优化，比如使用高精度定时器（
performance.now()）与内核空闲检测协同 - 但这种“突破”不可靠——一旦加入 DOM 操作、Promise 链或计算密集型同步代码，延迟立刻回归常规队列节奏
真正影响执行时机的，从来不是数字本身
比“4ms 是否存在”更重要的是理解 setTimeout 回调的落点位置：
立即学习“Java免费学习笔记（深入）”；
- 它总在当前宏任务结束、所有微任务清空、可选渲染完成之后才执行
-
setTimeout(() => console.log(1), 0)永远晚于Promise.resolve().then(() => console.log(2)) - 即使设为 1ms，若前序任务耗时 10ms，回调仍要等到第 10ms 末才入队，再等一轮循环才执行
避开陷阱的关键做法
不要对抗调度机制，而要适配它的节奏：
- 需要“尽快但不阻塞” → 用
queueMicrotask或Promise.then，而非setTimeout(..., 0) - 需要周期性执行且对帧率敏感 → 优先用
requestAnimationFrame，次选用requestIdleCallback - 做性能测量时，避开嵌套调用，用
performance.now()打点，而非依赖 setTimeout 时间参数 - 绝对不要用
while(Date.now() - start 实现延迟 —— 它锁死线程，彻底破坏事件循环
