当 settimeout 嵌套层级 ≥5 时，chrome 会将小于 4ms 的 timeout 值强制修正为 4ms，这是 html5 标准下的底层干预；node.js 无此限制，deno 和 bun 行为各异。
当 setTimeout 嵌套层级达到或超过 5 层时，浏览器（如 Chrome）会主动将小于 4ms 的 timeout 值强制修正为 4ms。这不是开发者代码控制的，而是运行时环境依据 HTML5 标准作出的底层干预。
嵌套层级怎么算？
每次 setTimeout 回调中再次调用 setTimeout，就增加一层嵌套。例如：
- 第一层：setTimeout(fn1, 0)
- 第二层：fn1 里调用 setTimeout(fn2, 0)
- 第三层：fn2 里调用 setTimeout(fn3, 0)
- ……直到第 5 层起，规则开始生效
为什么是 ≥5 层而不是 >5？
HTML5 标准写的是“嵌套层级大于 5”，但 Chrome 实际实现是 ≥5 就触发最小延时限制。这意味着第 5 次递归调用时，若传入 0、1、2 或 3ms，都会被自动拉高到 4ms。其他运行时行为不同：
- Node.js：无此限制，通常稳定在 1ms 左右
- Deno：≥5 层后启用 4ms 下限，但前几层也有约 1–3ms 延迟
- Bun：几乎无视 timeout 值，执行频率接近事件循环轮转速度
系统强制修正的触发条件
必须同时满足两个条件才会被“踩刹车”：
- 当前 setTimeout 调用处于第 5 层或更深的嵌套中
- 传入的 timeout 值小于 4（包括负数，此时先被归零，再比对是否
例如：setTimeout(() => {}, -1) 先被设为 0，再因嵌套 ≥5 被提升至 4；而 setTimeout(() => {}, 5) 不受影响，照常执行。
实际影响与规避建议
这种机制主要防止高频轮询拖慢页面、耗尽 CPU 或干扰用户交互。如果你发现定时器越来越“慢”，不是代码变慢了，而是嵌套触达阈值被限频了。可考虑：
- 改用 requestAnimationFrame 处理视觉更新类任务
- 用 setInterval 替代深层递归 setTimeout（注意手动清理）
- 拆分逻辑，避免在回调里连续 setTimeout，改用队列 + 时间片调度
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
