setTimeout 经常“迟到”是因为它只保证至少延迟指定时间后执行，实际受主线程阻塞、事件循环空闲时机及浏览器节流（如非激活标签页强制最小1000ms）影响；高精度场景应使用 performance.now() 配合轮询或 requestAnimationFrame 同步帧率。
setTimeout 为什么经常“迟到”？
因为 setTimeout 不是实时调度器，它只保证「至少等待指定毫秒后执行」，不保证「恰好在该毫秒执行」。实际延迟受 JS 主线程阻塞、事件循环空闲时机、浏览器节流（尤其标签页非激活时）共同影响。
常见现象：setTimeout(fn, 10) 在页面忙碌时可能拖到 30ms 甚至上百毫秒才触发；后台标签页中，浏览器会把最小间隔强制拉长到 1000ms 左右。
- 主线程正执行长任务（如大量 DOM 操作、复杂计算），回调必须排队等
- Chrome 对非活跃标签页的
setTimeout/setInterval施加最低 1000ms 节流 - 系统时间精度本身有限（Windows 默认 ~15.6ms，macOS ~1ms，但 JS 无法直接访问硬件时钟）
用 requestAnimationFrame 实现视觉帧级定时
当目标是动画或与屏幕刷新同步（比如每帧做一次状态检查），requestAnimationFrame 比 setTimeout 更可靠——它天然对齐显示器刷新率（通常 60Hz，即 ~16.7ms/帧），且不会被标签页节流。
但它不是“精确毫秒定时器”，而是“下一帧开始前执行”。适合：UI 更新、canvas 动画、滚动监听等场景。
let startTime = performance.now();
function tick(timestamp) {
const elapsed = timestamp - startTime;
console.log(`已运行 ${Math.round(elapsed)} ms`);
// 每约 16ms 触发一次（60fps）
requestAnimationFrame(tick);
}
requestAnimationFrame(tick);需要亚毫秒/高精度？用 performance.now() + 自旋校准
真正需要逼近物理时间（比如音频同步、游戏逻辑帧、性能采样），得放弃“定时触发”，改用“主动轮询+时间判断”。核心是：performance.now() 提供高精度单调递增时间戳（
精度通常达微秒级），配合短循环检测是否到达目标时刻。
⚠️ 注意：自旋会持续占用 CPU，仅适用于极短时间窗口（如
function preciseTimeout(callback, delayMs) {
const start = performance.now();
const target = start + delayMs;
function check() {
if (performance.now() >= target) {
callback();
} else {
// 用 setTimeout 做粗略等待，再用 loop 精调
setTimeout(check, 0.5); // 避免纯 while(true) 卡死主线程
}
}
check();
}
// 示例：期望 8.3ms 后执行（接近 120fps 帧间隔）
preciseTimeout(() => console.log('done'), 8.3);
Node.js 环境下可用 setImmediate 或 timer APIs
服务端没有页面可见性限制，但 setTimeout 仍受事件循环延迟影响。Node.js v19+ 提供了更底层的选项：
-
setImmediate()：在当前事件循环末尾执行（比setTimeout(fn, 0)更快，但仍是宏任务） -
timersPromises.setTimeout()（node:timers/promises）：返回 Promise，便于 await，语义更清晰 - 对极高精度需求（如金融交易时间戳），应依赖系统级 API（如
process.hrtime()）做差值计算，而非依赖定时器触发时机
真正难的不是“怎么写个更准的 setTimeout”，而是想清楚：你到底要对齐什么？是人眼感知（用 requestAnimationFrame），是服务端吞吐节奏（用 setImmediate 或队列），还是物理时间轴（靠 performance.now() / process.hrtime() 自行测量）——选错对齐基准，再“精确”的定时器也是南辕北辙。
