1. 单线程阻塞问题#

CAUTION

• JavaScript是单线程语言，所有代码在主线程中执行
• 当主线程被同步任务阻塞时(例如一个while循环)，定时器回调即使到期也无法按照预期执行

例如下面的代码，定时器回调实际执行时机 > 200ms :

setTimeout(() => console.log("本应100ms执行"), 100);

// 阻塞主线程200ms
const start = Date.now();
while(Date.now() - start < 200) {}

2. 事件循环优先级#

NOTE

• JavaScript是由事件驱动的。(它意味着 JavaScript 的执行流程不是完全由预先编写的代码顺序决定，而是由外部或内部发生的事件来触发和驱动)
• JavaScript 运行环境（浏览器、Node.js）的核心是一个持续运行的事件循环
• 即使定时器到期，其回调函数也不会立即执行：
  • 必须等待当前执行栈清空（同步代码）
  • 必须清空微任务队列（Promise.then、MutationObserver等）
  • 最后才执行宏任务（定时器回调）

TIP

所以，根据JS事件循环机制我们可以得出结论：定时器回调可能会被 其他同步代码/ 微任务队列 / 更早注册的(宏)任务 阻塞从而延迟。

3. 最小延迟限制#

WARNING

• 浏览器对定时器有最小延迟限制(通常是4ms)
• 嵌套定时器（层级>5）会被强制至少4ms延迟

4. 系统级限制#

WARNING

• 定时精度受操作系统调度影响
• 后台标签页的定时器会被节流（Chrome中≥1秒）
• 设备性能差异（低端手机更明显）

1. Web Workers:#

// 在worker线程执行精确计时
const worker = new Worker('timer-worker.js');

2.requestAnimationFrame (适合动画)#

function precisionTimer(callback) {
  let start = performance.now();
  
  function frame(time) {
    if(time - start >= 100) {
      callback();
    } else {
      requestAnimationFrame(frame);
    }
  }
  requestAnimationFrame(frame);
}

3. Performance API 校准#

const start = performance.now();

setTimeout(() => {
  const elapsed = performance.now() - start;
  console.log(`实际延迟: ${elapsed.toFixed(2)}ms`);
}, 100);

4. 优先使用微任务#

// 比setTimeout(0)更早执行
Promise.resolve().then(() => {...});