javascript定时器精度受操作系统定时分辨率限制，其物理天花板为1–15ms；主流浏览器设4ms下限是对此的实践经验收敛。
JavaScript 定时器的精度，本质上不是由 JS 自身决定的，而是被操作系统定时分辨率“托底”——它决定了 JS 能否拿到足够细的时间信号，也限制了浏览器底层能多快响应一次定时请求。
操作系统定时分辨率是 JS 定时器的物理天花板
现代操作系统（如 Windows、Linux、macOS）并不以“纳秒”为单位调度任务，而是依赖一个基础时间单元，叫 tick 或 quantum。这个值通常在 1–15ms 之间：
- Windows 默认系统 tick 为 15.625ms（即每秒约 64 次中断），可通过
timeBeginPeriod(1)临时调低，但需管理员权限且影响全局电源管理； - Linux 的
HZ配置决定 jiffy 粒度，常见值为 250（4ms）或 1000（1ms），但实际调度仍受 CFS 调度器和 CPU 频率波动影响； - macOS 使用 Mach timer，理论支持微秒级，但用户态应用（包括浏览器进程）仍受限于内核调度延迟和节能策略。
JavaScript 的 setTimeout 和 setInterval 最终依赖这些底层时钟源触发。即使你写 setTimeout(fn, 1)，操作系统可能根本不会在 1ms 后发出中断，浏览器也就无从“知道该唤醒 JS 线程”。这就是为什么所有主流浏览器都强制设定 4ms 最小延迟下限——它不是随意定的，而是对多数桌面系统实际调度能力的经验性收敛。
Java Linux版
下载
Java Linux版下载入口，提供 Oracle JDK 26.0.2 官方 Linux 安装包、Java 环境配置、JDBC 数据库连接和 Java 服务端开发相关信息。
JS 层无法绕过 OS 调度，但能缓解其影响
操作系统层的抖动（比如 CPU 切换、节电降频、GC 导致的线程暂停）会直接传导到 JS 定时行为。你看到的“100ms 定时器实际延迟 108ms”，其中前 4–6ms 往往就来自 OS 层未及时投递事件：
- Date.now() 返回的是系统 wall clock，受 NTP 校正、手动调时影响，不适合测间隔；
- performance.now() 基于单调时钟（如 Windows 的 QueryPerformanceCounter），精度可达微秒级，但它只是“测量工具”，不能提升触发时机本身；
- 真正能降低 OS 层干扰的做法，是把耗时逻辑移出主线程：Web Worker 不参与 UI 渲染调度，其
setTimeout更接近 OS 原生精度，再通过postMessage把结果交还给主线程。
后台标签与节能模式会主动放大 OS 分辨率误差
当页面不可见或设备进入省电状态，操作系统和浏览器会协同“放宽”定时约束：
- Chrome/Firefox 将后台标签的
setTimeout最小间隔拉高至 1000ms，这不是 bug，而是配合 OS 的 timer coalescing（定时器合并）机制——系统会把多个临近到期的定时器批量唤醒，减少 CPU 唤醒次数； - 笔记本在电池模式下，CPU 动态降频会导致
performance.now()的增量不再均匀，哪怕没做任何 JS 计算，两次采样差也可能跳变 ±3ms； - 这种放大效应让“OS 分辨率”从隐性限制变成显性瓶颈：原本 15ms 的系统 tick，在后台+节能双重作用下，可能等效于 500ms 以上的感知延迟。
不复杂但容易忽略——精度优化要分层看
想提升定时效果，不能只盯着 JS 写法：
- 对动画/渲染类任务，用
requestAnimationFrame，它直接绑定显示器刷新周期（通常 16.6ms），绕过 OS 定时器，也免受后台节流； - 对需要长期稳定间隔的任务（如心跳上报），应以服务端时间戳为锚点，前端仅做插值或补偿，避免累积漂移；
- 若必须高稳本地计时（如音频同步），需结合 Web Audio API 的
AudioContext.currentTime或performance.timeOrigin，它们底层对接更稳定的硬件时钟源。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
