浏览器将 settimeout 最小延迟设为 4ms：html 标准强制要求嵌套超 5 层且 delay＜4ms 时修正为 4ms；主流浏览器全局统一提升＜4ms 的 delay 至 ≥4ms，以平衡性能、功耗与调度稳定性。
因为浏览器遵循 HTML 标准，对定时器设置了最小延迟兜底值——当嵌套层级超过 5 层且设置的 delay 小于 4ms 时，自动修正为 4ms；同时，现代浏览器普遍将 4ms 作为所有 setTimeout 的实际下限，无论是否嵌套，这是为了平衡性能、功耗与任务调度稳定性。
HTML 标准明确规定的兜底机制
WHATWG 维护的 HTML Living Standard 在“Timers”章节中写明：
- 如果定时器嵌套层级（timer nesting level）超过 5，且传入的 delay 小于 4ms，则强制设为 4ms
- 该限制不是可选行为，而是浏览器必须遵守的规范要求
- 嵌套指在 setTimeout 回调里再次调用 setTimeout，连续 6 次即触发该规则
浏览器主动实施的全局最小延迟
即便不满足嵌套条件，Chrome、Firefox、Safari 等主流引擎仍默认将任何小于 4ms 的 delay（包括 0ms）统一提升至 ≥4ms：
- 防止高频调度导致主线程过载，避免 UI 卡顿或动画掉帧
- 降低移动端 CPU 占用与发热，延长电池续航
- 减少任务队列频繁插入带来的调度开销
它本质不是“不准”，而是“有意节流”
setTimeout 的设计目标从来不是高精度计时，而是提供一种“主线程空闲后尽快执行”的异步调度能力：
- 回调始终作为宏任务进入队列，需等同步代码 + 所有微任务执行完毕
- 即使队列为空，也受 4ms 限制，不会真正“零延迟”执行
- 页面切到后台时，延迟还会进一步拉长（如升至 1000ms），这是额外节流
替代方案比“绕过”更实用
与其试图突破 4ms 限制，不如根据场景选择更匹配的 API：
- 做动画：用 requestAnimationFrame，它绑定浏览器重绘节奏，通常每 16.7ms 一次，更稳定
- 做高精度倒计时：用 performance.now() 动态校准每次 delay，补偿累积误差
- 做密集计算：移至 Web Worker，避免阻塞主线程影响定时器响应
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
