JavaScript定时器回调不能即时执行，根本原因是其单线程机制：回调仅在主线程空闲、微任务清空、事件循环进入timers阶段后才执行；主线程阻塞、微任务优先及浏览器节流均会导致实际延迟远超设定值。
定时器回调不能即时执行，根本原因在于 JavaScript 是单线程语言，所有代码（包括定时器回调）都必须排队等待主线程空闲才能运行。它不承诺“准时”，只保证“至少延迟指定时间后执行”。真正决定执行时机的，是事件循环是否已完成当前同步任务、清空微任务队列，并进入 timers 阶段。
定时器不是倒计时闹钟，而是“排队申请”
调用 setTimeout(fn, 10) 并不会启动一个独立的倒计时线程。浏览器只是记录下“10ms 后可排队”，到了时间点，把回调放入宏任务队列——但它不会立刻执行，必须等：
- 当前同步代码全部跑完
- 本轮所有微任务（如 Promise.then、queueMicrotask）执行完毕
- 事件循环进入下一轮的 timers 阶段，且该回调已满足时间阈值
主线程阻塞会直接拉长实际延迟
如果主线程正在执行耗时操作（比如大数组遍历、复杂计算或死循环），定时器即使到期也无法插队。它的回调只能在队列里等待，直到主线程释放控制权。
例如：
设了 setTimeout(fn, 10)，但紧接着一个持续 200ms 的 while 循环——fn 实际执行时间可能接近 210ms，甚至更久。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
微任务总比定时器优先级高
Promise.then、MutationObserver 回调等微任务，会在每个宏任务结束后立即执行，不给 timers 阶段插队机会。这意味着：
- 哪怕你设了
setTimeout(fn, 0)，它仍排在所有微任务之后 - 一个密集的 Promise 链，可能让定时器连续推迟多个 tick
- 它和
Promise.resolve().then()的执行时机不同：后者属于微任务，前者属于宏任务
浏览器节流会让定时器进一步失准
在页面不可见、后台标签页、系统资源紧张等情况下，浏览器会主动降低定时器频率（如将最小间隔从 4ms 提升到 1000ms），尤其影响 setInterval。这是为节省资源做的合理限制，但会导致预期节奏完全错乱。
例如：标签页切到后台时，原本每 100ms 执行一次的 setInterval 可能变成每秒才触发一次，甚至被合并或跳过。
