定时器执行时间不精确，实际回调受事件循环、任务队列和主线程负载影响；到期后进入宏任务队列等待执行，误差需用performance.now()量化并批量统计分析。
JavaScript 中定时器（setTimeout 和 setInterval）的执行时间并非精确，而是受事件循环机制、任务队列状态、主线程繁忙程度等多重因素影响。所谓“延时误差”，是指定时器注册后，实际回调执行时间与预期时间之间的偏差。要分析这个误差，关键不是看设定值，而是观察它在真实运行环境中的表现逻辑。
定时器不是“准时钟”，而是“时机检查点”
定时器一旦到期，并不会立即执行回调，而是将回调推入宏任务队列（macrotask queue），等待当前执行栈清空、且轮到该宏任务被事件循环取出时才执行。这意味着：
- 如果主线程正执行一个耗时 200ms 的同步任务，即使
setTimeout(fn, 0)已到期，fn也至少要等这 200ms 结束后才可能执行； -
setTimeout(fn, 10)在理想空闲环境下可能 12–15ms 后执行，但若此时有大量微任务或长任务排队，延迟可能达几十甚至上百毫秒； - 浏览器对非常小的延迟（如
）会自动调整为至少 4ms（HTML 规范要求），这是底层限制，非代码可绕过。
用高精度时间戳量化误差
避免依赖 console.time() 或简单差值，改用 performance.now() 获取亚毫秒级单调递增时间戳，对比“理论触发时刻”和“实际执行时刻”：
const start = performance.now();
const delay = 50;
setTimeout(() => {
const actualDelay = performance.now() - start;
console.log(`设定 ${delay}ms，实际延迟 ${actualDelay.toFixed(2)}ms，误差 ${((actualDelay - delay)).toFixed(2)}ms`);
}, delay);
多次运行并统计（如取中位数、最大偏差、标准差），能反映当前环境下的典型误差分布。注意：单次结果意义有限，需批量采样。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
识别误差来源：是调度延迟，还是执行阻塞？
误差常被误认为“定时器不准”，实则多数源于执行环境。可通过以下方式归因：
-
检查是否被长任务阻塞：用
PerformanceObserver监听longtask，确认是否有 >50ms 的同步任务正在运行； -
观察微任务影响：大量
Promise.then或MutationObserver回调虽不阻塞宏任务入队，但会延长本轮循环，间接推迟下一轮宏任务（含定时器）的处理时机； -
验证页面可见性与节流：标签页处于后台时，浏览器会大幅降低定时器频率（如降为 1s 一次），
document.hidden为true时误差会剧增； -
排除渲染帧干扰：若定时器用于动画，建议改用
requestAnimationFrame，它与屏幕刷新节奏对齐，无此类调度误差。
可控优化方向：减少不可控延迟
无法消除误差，但可压缩其波动范围：
- 避免在定时器回调中执行重计算、DOM 批量操作或同步网络请求；
- 用
setImmediate（Node.js）或queueMicrotask（浏览器）替代极短延时（ - 对精度敏感场景（如音频同步、游戏逻辑），采用自适应补偿：记录前几次误差，动态调整下次定时器的 delay 值；
- 使用
Worker运行独立定时逻辑，避开主线程干扰，再通过postMessage通信——适合纯计算型周期任务。
定时器误差本质是 JavaScript 单线程 + 事件驱动模型的自然产物，不是 bug。理解它如何被事件循环调度、用正确工具测量、区分“调度延迟”与“执行延迟”，才能合理设计健壮的时间敏感逻辑。
