setTimeout未按预期延迟执行的根本原因是事件循环机制：主线程忙时回调需等待当前任务完成，实际延迟=指定延迟+主线程占用时长；应避免同步阻塞、用递归setTimeout替代setInterval、及时清除定时器并注意跨平台差异。
setTimeout 为什么没按预期延迟执行
常见现象是写 setTimeout(fn, 1000) 后，fn 立刻执行或延迟远超 1s。根本原因不是定时器不准，而是 JavaScript 的事件循环机制：如果主线程正忙（比如在跑一个长循环或同步阻塞操作），setTimeout 的回调只能等当前任务完成后再入队，实际延迟 = 指定延迟 + 主线程占用时长。
实操建议：
- 避免在定时器外写耗时同步代码，比如
for (let i = 0; i - 若需“精确”延时（如动画帧对齐），优先用
requestAnimationFrame；真要毫秒级控制，得结合performance.now()手动校准 -
setTimeout返回一个数字 ID，可用于后续clearTimeout，这点常被忽略导致内存泄漏
setInterval 容易累积执行或卡死的真相
很多人以为 setInterval(fn, 100) 就是“每 100ms 执行一次”，但若 fn 执行时间 > 100ms（比如网络请求未返回、DOM 操作卡顿），浏览器不会跳过或合并任务，而是把回调持续压入任务队列——结果就是多个 fn 实例排队等待执行，界面卡顿甚至崩溃。
实操建议：
- 用
setTimeout递归替代setInterval，确保上一次执行完才安排下一次：function loop() { doWork(); setTimeout(loop, 100); } setTimeout(loop, 100); - 对异步操作（如
fetch），务必在回调里重新触发下一轮，别依赖固定间隔 -
setInterval的 ID 同样要存好，页面卸载前必须clearInterval，否则监听器残留
清除定时器时容易漏掉的三种情况
清除失败不是因为语法错，而是生命周期管理疏忽。最典型的是：组件销毁了，但定时器还在跑；或者函数重定义后，旧 ID 变成无效引用。
关键点：
- React 中，在
useEffect的清理函数里调用clearTimeout或clearInterval，且依赖数组不能漏掉影响定时器状态的变量 - Vue 2 的
beforeDestroy或 Vue 3 的onBeforeUnmount必须处理，尤其在v-if切换时容易遗漏 - 不要在闭包里反复创建新定时器却不存 ID，比如每次点击按钮都
setInterval(...)却不clear上一个
Node.js 环境下这两个 API 的行为差异
浏览器和 Node.js 都支持 setTimeout/setInterval，但底层调度不同：Node.js 使用 libuv 的事件循环，对 I/O 密集型任务更敏感；而浏览器受制于标签页可见性策略（比如后台标签页会节流 setInterval 到最低 1s）。
注意：
- Node.js 中
setTimeout(fn, 0)不一定比setImmediate先执行，具体取决于当前事件循环阶段 - 浏览器里
setTimeout(fn, 0)是把任务推到下一个宏任务队列，而Promise.then是微任务，后者一定更早 - 跨平台代码若依赖定时精度，建议封装一层适配逻辑，别直接裸用原生 API
