浏览器对定时器嵌套第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 层即触发限制。设计逻辑很直接：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 前 5 层允许极短延迟（实测常为 0.3–1.2ms），保留一定灵活性
- 第 6 层起视为“潜在失控风险”，浏览器主动介入降频，避免单个脚本通过
setTimeout(fn, 0)形成高频宏任务洪流 - 这本质上是一种反 DoS（拒绝服务）保护，防止页面卡死、耗尽 CPU 或快速耗尽移动设备电量
4ms 是平衡性能与精度的工程取舍
这个数值并非随意设定，而是综合多方面考量的结果：
立即学习“Java免费学习笔记（深入）”；
- 人眼感知阈值：低于 16ms（60fps）的视觉变化已难察觉，4ms 远高于渲染帧率需求下限
- 系统调度开销：操作系统定时器本身存在分辨率限制（如 Windows 多数为 15ms），强行追求亚毫秒反而失真
- 功耗控制：尤其在移动端，频繁唤醒 CPU 会显著缩短续航，4ms 是兼顾响应性与能效的经验值
后台标签页会进一步恶化这一限制
即使满足规范条件，实际行为还受运行环境影响：
- 页面切到后台时，Chrome/Firefox 会把最小延迟拉高至 ≥1000ms
- 部分 Firefox 版本在后台开启脚本追踪后，延迟可达 ≥10000ms
- Web AudioContext 正在播放（哪怕静音）可绕过该降级，但需显式调用
audioContext.resume()
