第6层起settimeout(0)强制≥4ms是html标准规定的节流机制；前5次约0.3–1.2ms，第6次起跳至4–6ms；层级按宏任务调用链累计，与缩进或中间异步操作无关；非活跃标签页延迟升至1000ms或10000ms。
setTimeout 的嵌套层级直接影响实际延迟——不是代码缩进或函数嵌套深度，而是宏任务调用链上连续 setTimeout 调用的次数。从第 6 次开始，浏览器强制将 delay ≥ 4ms，这是 HTML 标准规定，不是 bug，也不可绕过。
什么是“嵌套层级”？
层级按宏任务调度路径累计，每次 setTimeout 调用都算一层，与中间是否穿插 Promise、fetch 或其他异步操作无关。例如：
- A → setTimeout(B) 是第 1 层
- B → setTimeout(C) 是第 2 层
- ……
- F → setTimeout(G) 就是第 6 层，此时即使写 setTimeout(fn, 0)，实际延迟也会跳到 4–6ms
前 5 层仍可能接近 0ms（实测常为 0.3–1.2ms），但第 6 层起节流立即生效。
为什么是第 6 层触发限制？
HTML Living Standard 明确规定：嵌套层级 ≥ 6 且 timeout
非活跃标签页会进一步放大延迟
用户切换离开当前标签页后，该限制会叠加更严苛的后台节流：
- Chrome / Firefox 桌面版：setTimeout(0) 延迟升至 ≥ 1000ms
- Firefox 开启脚本追踪后：延迟可达 ≥ 10000ms（10 秒），且从页面加载完成 30 秒后开始生效
- 例外：页面正在播放 Web Audio（哪怕静音），调用 audioContext.resume() 后可绕过此后台节流
替代方案比“绕过”更有效
试图用 postMessage、MessageChannel 或 setImmediate（已废弃）欺骗层级计数，现代浏览器已统一纳入节流范围。真正需要高精度调度时，应换用：
- queueMicrotask：不计入宏任务层级，无 4ms 限制，适合“尽快脱出当前执行栈”
- requestAnimationFrame：绑定屏幕刷新节奏（约 16.7ms），适合动画类任务
- WebAssembly + Atomics.wait（仅 Worker 中）：实现亚毫秒级等待，适用于音频采样等硬实时场景
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
