setTimeout只执行一次，setInterval按间隔重复执行；两者均需手动清除ID以防内存泄漏；setTimeout(fn,0)因任务队列机制并非立即执行；高精度场景应基于时间戳计算而非依赖定时器延迟。
setTimeout 和 setInterval 的核心区别在哪？
两者都用来延迟执行代码，但行为完全不同：setTimeout 只触发一次，setInterval 会按固定间隔重复触发。如果你只想在 3 秒后执行一段逻辑，用 setTimeout；如果要做轮询（比如每 500ms 检查一次状态），才该用 setInterval。
常见错误是误用 setInterval 去实现“只执行一次”的需求，结果造成多次叠加执行，尤其在组件反复挂载/卸载场景下容易内存泄漏或逻辑错乱。
如何精确控制定时器的启停和清理？
所有定时器都必须手动清除，否则即使页面跳转或组件销毁，它们仍在后台运行，消耗资源并可能引发报错。
-
setTimeout返回一个数字 ID，用clearTimeout(id)清除 -
setInterval同样返回 ID，用clearInterval(id)清除 - React 中推荐在
useEffect的清理函数里清除；Vue 中在onBeforeUnmount或beforeDestroy钩子中处理 - 避免把定时器 ID 存在局部变量里就不管了——它必须被后续可访问的逻辑引用到才能清除
为什么 setTimeout(fn, 0) 不是立刻执行？
因为 JavaScript 是单线程的，setTimeout 的回调会被推入任务队列（task queue），等当前调用栈清空、宏任务执行完后才执行。所以 setTimeout(fn, 0) 实际执行时机取决于主线程是否空闲，通常在几毫秒之后，不是“零延迟”。
立即学习“Java免费学习笔记（深入）”；
如果需要更精细的调度（比如让渲染优先于计算），可考虑 queueMicrotask 或 requestIdleCallback，但要注意兼容性：
-
queueMicrotask属于微任务，会在当前宏任务末尾立即执行，适合轻量级异步衔接 -
requestIdleCallback在浏览器空闲时调用，适合非紧急的低优先级任务（如日志上报），但部分旧版 Safari 不支持
定时器时间不准？可能是这些原因
浏览器标签页休眠、系统节电策略、高负载任务阻塞都会导致定时器延迟。例如：用户切走标签页超过 1 分钟，Chrome 会将 setInterval 最小间隔限制为 1000ms；Node.js 环境中则受事件循环阻塞影响更大。
真正需要“准点”执行的场景（如倒计时显示），不能依赖定时器本身，而应记录起始时间戳，每次执行时用 Date.now() 计算已过时间：
const start = Date.now();
const duration = 5000;
const timer = setInterval(() => {
const elapsed = Date.now() - start;
const remaining = Math.max(0, duration - elapsed);
if (remaining <= 0) {
clearInterval(timer);
}
}, 100);这种写法能避免因延迟累积导致倒计时跳变或不准，但要注意别把检查间隔设得太短（比如 1ms），否则频繁计算反而拖慢性能。
定时器最常被忽略的一点：它不保证执行时间，只保证“至少延迟这么久”。真正的时间敏感逻辑，永远要靠时间戳校准，而不是相信 delay 参数。
