您之前总结的关于 JavaScript 定时器在高负载下“必然延迟”的观点，其实已经点明了核心逻辑。但很多人看完依然会问：“那我到底该怎么写代码？” 今天我们就把它拆开揉碎了聊一遍——这不是你代码写得“不够努力”，而是事件循环机制和宿主环境压根就没承诺过“准时”。 先看第一层问题：**主线程一卡，定时器全得排队**。 所有 setTimeout 和 setInterval 的回调，在底层都属于宏任务。宏任务进入任务队列后，必须等待当前调用栈清空、所有微任务执行完毕、浏览器渲染完成后才能轮到它们。一旦主线程出现以下情况，回调就只能干等着： - 同步计算密集，例如大数组排序、JSON.parse 一个几十 MB 的字符串； - 长时间 DOM 操作或样式重排重绘； - 未优化的 while 循环或递归逻辑。 举例来说：一个耗时 200ms 的同步任务执行完毕后，即使你之前设置的定时器是 10ms，实际触发时间也会延迟超过 200ms——你根本无法控制。 你可能会问：“那我换 setInterval 行吗？” 不行，本质一样。 关键的第二层来了：**CPU 高负载会把底层定时器偏差放大到离谱**。 定时器精度不是单靠 JavaScript 引擎决定的，它要经过操作系统调度、libuv（Node 端）或浏览器定时器线程、V8 执行层这三层，每一层都可能产生偏差。CPU 一高，偏差连锁放大： - OS 调度层：内核可能延长 Node 进程的时间片等待，尤其是多进程抢资源时； - libuv 层（Node）或浏览器定时器线程：Linux 使用 setitimer、Windows 使用 WaitForMultipleObjectsEx，原生精度只有 10~15ms；负载一高，中断响应变慢； - V8 执行层：GC 频繁触发、JIT 编译暂停、代码去优化……单次事件循环耗时增加，间接推迟宏任务入队。 有人做过实测：Ubuntu + Node.js v20.15 下，10ms 定时器在空闲系统平均延迟 13.2ms；CPU 持续 75% 负载时，平均延迟飙到 58.7ms，标准差 ±24.6ms。极端同步阻塞下，甚至回调直接“丢”了——不是延迟，而是压根没触发。 还有第三层：**后台节流和系统节能，宿主主动“毁约”**。 Chrome、Firefox 在页面失焦时，会把 setInterval 的最小间隔强制拉高到 ≥1000ms；笔记本合盖、电池供电模式下，操作系统会主动降低 CPU 频率，影响底层定时器基准稳定性；移动端浏览器更激进，部分场景延迟可达数秒。 这都不是 bug，而是宿主环境为了保性能、省电所采取的策略设计。你只能接受，然后适配。 那真正该怎么做？**不是提高频率，而是放弃对固定间隔的依赖**。 高频 setInterval 或嵌套 setTimeout 不仅无法提升精度，反而可能触发浏览器的节流机制——比如 Chrome 对第 5 层嵌套的 setTimeout 限为 4ms。更可靠的做法是： - 用 **performance.now()** 记录起始时间，每次执行时计算真实经过时间，再决定是否触发逻辑（倒计时、轮询都适用）； - 动画类任务优先用 **requestAnimationFrame**，它跟屏幕刷新率对齐，比 setInterval 稳定得多； - CPU 密集任务扔给 **Worker Threads**（Node）或 **Web Worker**（浏览器），别堵着主线程； - 生产环境部署前，用 **monitorEventLoopDelay()** 监控 P99 事件循环延迟，超过 50ms 就预警。 说到底，定时器的“准”只是理想模型，现实永远有偏差。理解它，接受它，然后用对手段绕过去。