settimeout 由宿主环境独立定时器系统管理，js 引擎不参与调度；浏览器用红黑树/小根堆维护定时器，os 通过事件通知唤醒；node.js 借 libuv 最小堆+系统 i/o 实现；受时钟精度、事件循环负载和节流策略影响，执行不精确。
setTimeout 的底层并不依赖 JavaScript 引擎自身的“时钟队列”，而是由宿主环境（浏览器或 Node.js）提供独立的定时器系统来管理。JS 引擎本身是单线程、无内置时钟的，它只负责执行任务；真正的延时调度、到期判断和任务唤醒，全部交由底层运行时完成。
浏览器中的定时器模块与最小粒度控制
现代浏览器（如 Chromium）使用高精度系统时钟（如 clock_gettime(CLOCK_MONOTONIC)）配合红黑树或小根堆维护待触发定时器。每个 setTimeout 调用会生成一个定时器节点，按到期时间插入排序结构中。主线程不轮询，而是由操作系统在时间点到达时通过事件通知（如 epoll/kqueue 或 Windows I/O Completion Port）唤醒运行时的事件循环线程。
- HTML5 规定最小延迟为 4ms（前台页面），后台标签页则可能放宽至 1000ms 以节省电量
- 当大量定时器集中到期，运行时会批量取出并依次加入宏任务队列，而非逐个唤醒
- 即使设置
setTimeout(fn, 0)，也必须等当前宏任务（包括所有同步代码和本轮微任务）结束后，才可能执行——它只是“尽快”，不是“立即”
Node.js 的 libuv 定时器实现
Node.js 借助 libuv 库实现跨平台定时器。libuv 在事件循环中维护一个最小堆（min-heap），键为绝对到期时间戳。每次循环迭代前，它检查堆顶是否已到期；若到期，则弹出并触发回调。未到期时，libuv 会调用 epoll_wait（Linux）或 kevent（macOS）并传入剩余等待时间，让内核在精确时刻唤醒进程。
- libuv 不使用 busy-wait，也不创建新线程，完全基于系统级异步 I/O 机制
- 定时器回调被封装为
uv_timer_thandle，其就绪状态由事件循环统一调度 - 频繁创建/清除短间隔定时器（如
setInterval(fn, 1)）会导致堆频繁调整，影响性能
CPU 唤醒并非由 JS 主动触发
JavaScript 代码本身无法“唤醒 CPU”。所谓“唤醒”，实际是运行时系统借助操作系统能力，在预定时间点将休眠的线程重新调度到 CPU 核心上执行。这个过程对 JS 完全透明：
- 浏览器渲染进程通常处于 event loop 空转状态（如
epoll_wait阻塞），此时 CPU 使用率接近 0% - 定时器到期 → 内核发出就绪通知 → 运行时线程被调度器选中 → 从阻塞态转为运行态 → 执行回调
- 没有“JS 线程每毫秒检查一次”的轮询行为；轮询既低效又违背异步设计初衷
为什么 setTimeout 不保证精确执行？
实际延迟受三重因素叠加影响：
- 系统时钟精度：不同平台 timer resolution 不同（Windows 默认约 15.6ms，Linux 可达微秒级但受调度策略限制）
- 事件循环负载：若前序宏任务耗时过长（如长循环、大数组排序），即使定时器已到期，回调也要排队等待
- 浏览器节流策略：页面不可见、电池供电、帧率限制等场景下，运行时会主动拉长定时器间隔
