定时器最小延迟为4ms是HTML标准规定的节流策略，嵌套5–6层后强制钳制；非活动标签页延至1000ms以上；事件循环与系统底层共同导致延迟不可控。
定时器最小延迟为 4ms 是浏览器的主动限制
这不是 JavaScript 引擎的缺陷，而是 HTML Living Standard 明确规定的节流策略。当 setTimeout 或 setInterval 的嵌套调用达到第 5 层（Chrome/Firefox）或第 6 层（Safari）时，浏览器会强制将延迟值“钳制”（clamped）到至少 4 毫秒。目的是防止脚本通过无限递归调用定时器持续抢占主线程，导致页面卡死或耗电激增。
例如连续五次 setTimeout(cb, 0) 嵌套后，第六次实际延迟往往跳升至 4–6ms，而非理论上的“立即”。这个限制对所有宏任务调度生效，包括由 setInterval 触发的重复回调。
非活动标签页会进一步放大延迟
当用户切换离开当前网页标签时，浏览器会大幅降低后台 tab 的定时器精度以节省资源：
- 多数现代浏览器（Chrome ≥11、Firefox ≥5）将
setTimeout最小间隔提升至 1000ms - 某些移动端或低功耗场景下，甚至可能延长到数秒或直接暂停定时器
- 这种节流独立于代码逻辑，无法通过调整 delay 参数绕过
这意味着一个前台运行正常的倒计时，在切到其他标签后可能每秒只更新一次，且时间戳跳跃明显。
立即学习“Java免费学习笔记（深入）”；
事件循环机制天然导致“延迟不可控”
定时器回调属于宏任务，它的执行时机取决于三个关键条件同时满足：
- 计时器已到达设定时间点（仅表示“可入队”，不保证“立刻执行”）
- 当前执行栈完全清空（无同步代码、无正在运行的 Promise 回调等）
- 微任务队列已全部处理完毕（如
Promise.then、MutationObserver）
只要其中任一条件未满足，回调就会排队等待。比如一个 10ms 定时器，若此时主线程正执行一个 80ms 的 DOM 批量操作，真实执行时间就可能落在 90ms 之后——这和 4ms 限制无关，而是单线程调度的本质决定的。
系统与硬件层面也存在底层约束
即使浏览器完全空闲，定时器仍受操作系统和 CPU 调度影响：
- 系统定时器粒度通常在 10–16ms（尤其 Windows 默认多媒体定时器精度）
- CPU 上下文切换、缓存未命中、电源管理策略（如节能模式降频）都会引入额外抖动
-
performance.now()虽高精度，但只能测量已发生的时间，不能消除底层延迟
实测中，在轻负载桌面环境，普通 setTimeout(..., 10) 的实际偏差常在 1–8ms；而在低端 Android 设备或后台 tab 中，偏差可达数百毫秒甚至失效。
