settimeout 是 javascript 中用于延迟执行一次回调的异步机制，不保证精确延时，因其实际执行依赖主线程空闲、事件循环状态及浏览器节流策略。
setTimeout 是什么，为什么它不保证精确延时？
setTimeout 是 JavaScript 中最基础的异步定时机制，用于在指定毫秒数后执行一次回调函数。但它不是“准时钟”，而是“尽最大努力按时触发”——实际执行时间取决于当前调用栈是否为空、事件循环是否空闲、以及是否有更高优先级任务（比如渲染、用户输入）正在排队。
常见误解是以为 setTimeout(fn, 1000) 一定在 1000ms 后立刻执行；实际上它只保证「至少等待 1000ms」，之后等主线程空闲才真正调用。
- 如果主线程正执行一个耗时 2s 的
while循环，即使设了setTimeout(..., 100)，回调也要等到循环结束才执行 -
浏览器对嵌套过深或频繁创建的
setTimeout可能做节流（如最小间隔限制为 4ms） - 页面被切换到后台时，大多数浏览器会将
setTimeout的最小间隔拉长至 1000ms 左右，以节省资源
如何正确使用 setTimeout 延迟执行代码？
核心是把要延迟执行的逻辑封装成函数，并传给 setTimeout，同时注意 this 绑定、参数传递和清理需求。
- 不要写
setTimeout(fn(), 1000)—— 这会立即执行fn()，把返回值当回调传入；应写setTimeout(fn, 1000)或setTimeout(() => fn(), 1000) - 需要传参时，推荐用箭头函数包裹，避免
setTimeout(fn, 1000, arg1, arg2)在旧版 Safari 中不兼容 - 如果该定时器可能被重复设置（比如按钮连点），记得先用
clearTimeout清掉前一个，否则会累积多个待执行回调
let timerId = null;
function delayedSave(data) {
clearTimeout(timerId); // 防重复触发
timerId = setTimeout(() => {
console.log('saving:', data);
// 实际保存逻辑
}, 500);
}
setTimeout 和 setInterval 有什么关键区别？
setTimeout 只执行一次，setInterval 按固定间隔重复执行——但它们底层都依赖事件循环，且都受主线程阻塞影响。
立即学习“Java免费学习笔记（深入）”；
-
setInterval不会跳过“丢失”的周期：如果某次回调执行耗时超过设定间隔（比如setInterval(fn, 100)，但fn耗时 150ms），下一次回调会在上一次结束后立刻开始，不会补上“欠的那 50ms” - 想实现“严格按间隔执行”，得用
setTimeout递归调用，自己控制下次触发时间点 -
setInterval更难清理：必须显式保存返回的 id 并调用clearInterval(id)，漏掉就会内存泄漏
let intervalId = setInterval(() => {
console.log('tick');
}, 1000);
// ✅ 正确清理
clearInterval(intervalId);
什么时候不该用 setTimeout 做延迟？
当延迟目的不是“等一段时间”，而是“等某个条件成立”或“等某个操作完成”，setTimeout 就容易出错或不可靠。
- 等 DOM 元素挂载完成？用
requestAnimationFrame或MutationObserver，而不是setTimeout(..., 0) - 等 Promise 结果？直接
await或.then()，别用setTimeout硬等 - 做防抖/节流？用专门的逻辑控制，而不是靠
setTimeout+ 全局变量拼凑，易出竞态 - 需要高精度计时（如音频同步、游戏帧逻辑）？浏览器 API 本身就不适合，应考虑
performance.now()配合 requestAnimationFrame
真正需要延迟的场景其实很窄：UI 提示自动关闭、简单轮询兜底、模拟异步响应——其余多数情况，都有更语义明确、更可控的替代方案。
