浏览器对定时器嵌套第6层起强制设最小延迟为≥4ms，是html标准规定的节流机制，旨在防止脚本无限抢占主线程，属反dos保护；4ms为兼顾人眼感知、系统调度与移动功耗的工程取舍。

浏览器对定时器嵌套超过五层后强制设为 ≥4ms，不是实现缺陷，而是 HTML 标准明确规定的节流机制——核心目的是防止脚本无限抢占主线程资源。

这是 HTML 规范的硬性要求

WHATWG 维护的 HTML Living Standard 在“Timers”章节中白纸黑字规定：

• 当定时器嵌套层级（timer nesting level）大于 5，且传入的 delay 小于 4ms 时，浏览器必须将 delay 提升至至少 4ms
• 该行为是强制性的，所有主流浏览器（Chrome、Firefox、Safari、Edge）均需遵守
• 所谓“嵌套层级”，指连续在 setTimeout 回调中再次调用 setTimeout 所形成的宏任务链深度，和代码缩进、是否夹杂 Promise 无关

为什么是“第 6 层”触发，而不是第 5 层？

层级从第 1 次 setTimeout 调用开始计数：第 1 层 → 第 2 层 → … → 第 6 层即触发限制。设计逻辑很直接：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 前 5 层允许极短延迟（实测常为 0.3–1.2ms），保留一定灵活性
• 第 6 层起视为“潜在失控风险”，浏览器主动介入降频，避免单个脚本通过 setTimeout(fn, 0) 形成高频宏任务洪流
• 这本质上是一种反 DoS（拒绝服务）保护，防止页面卡死、耗尽 CPU 或快速耗尽移动设备电量

4ms 是平衡性能与精度的工程取舍

这个数值并非随意设定，而是综合多方面考量的结果：

• 人眼感知阈值：低于 16ms（60fps）的视觉变化已难察觉，4ms 远高于渲染帧率需求下限
• 系统调度开销：操作系统定时器本身存在分辨率限制（如 Windows 多数为 15ms），强行追求亚毫秒反而失真
• 功耗控制：尤其在移动端，频繁唤醒 CPU 会显著缩短续航，4ms 是兼顾响应性与能效的经验值

后台标签页会进一步恶化这一限制

即使满足规范条件，实际行为还受运行环境影响：

• 页面切到后台时，Chrome/Firefox 会把最小延迟拉高至 ≥1000ms
• 部分 Firefox 版本在后台开启脚本追踪后，延迟可达 ≥10000ms
• Web AudioContext 正在播放（哪怕静音）可绕过该降级，但需显式调用 audioContext.resume()

不复杂但容易忽略

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南