console.log("开始");
setTimeout(() => { console.log("定时器到了！"); }, 0); // 延迟设为0
console.log("结束");

开始
结束
定时器到了！

console.log("开始");

setTimeout(() => { console.log("Timeout!"); }, 1000); // 计划1秒后执行

const startTime = Date.now();
while (Date.now() - startTime < 3000) { // 模拟一个耗时3秒的复杂计算
    // 这里啥也不干，就是空等3秒，占住主线程
}

console.log("结束");

开始
（这里卡顿3秒...）
结束
Timeout! (在 "开始" 打印后大约3秒多才出现)

function doSomething() {
    console.log("干活了...");
    // 假设这里可能也有点耗时操作...
    setTimeout(doSomething, 1000); // 干完再计划下一次
}
doSomething(); // 启动

setInterval： 这个函数就是设计来重复执行的。它会尝试每隔指定的时间（比如1000ms）就把回调函数放进队列一次。但是，它有个问题叫“累积效应”：如果回调执行时间比间隔时间长，那么下一次回调会立刻执行（或者连续堆积起来），而不是等间隔时间。所以它也不是绝对精确。

requestAnimationFrame (做动画首选)： 浏览器专门为流畅动画设计的。它会在每次屏幕刷新前调用你的函数（通常是每秒60次）。用它做动画最合适，能保证流畅度，并且浏览器在标签页不可见时会自动暂停，省资源。

基于时间差计算： 对于需要精确时间间隔但又不能用 requestAnimationFrame 的情况（比如不是动画），可以在每次回调里记录实际过去的时间，然后计算下一次需要执行的时间点。这能减少累积误差。

页面或组件卸载了： 在 react, vue 这些框架里，如果你在一个组件里设置了定时器，但组件被销毁（比如页面跳转、组件隐藏）时没清除它，定时器虽然可能还在，但回调函数执行时组件状态可能已经无效了，导致看起来没执行，甚至报错。关键：组件卸载前务必用 clearTimeout 清理定时器！

被清除了： 你或者某个库的代码主动调用了 clearTimeout，传入了正确的定时器ID。

浏览器标签页在后台： 为了省电和省资源，现代浏览器（Chrome, Firefox, Safari 等）会对后台标签页（不是当前你看的那个标签）里的定时器进行“节流”。延迟很短（比如几秒）的定时器可能被延迟执行，非常短的（如动画用的）可能被暂停。Chrome 对后台标签页的非活动定时器，延迟时间可能被限制到至少1分钟（1000ms以上）甚至更长（如10分钟）！当你切回标签页时，它们才会被处理。

环境不同： 你的代码可能运行在 Web Worker 或 Node.js 环境里，它们处理定时器的机制和浏览器主线程不完全一样。

for (var i = 0; i < 5; i++) {
    setTimeout(function() {
        console.log(i); // 期待0,1,2,3,4？实际输出：5,5,5,5,5
    }, 1000);
}

用 let（推荐）： let 是块级作用域。每次循环都会创建一个新的 i，每个定时器回调都绑定了自己循环那次的那个 i 的值。

for (let i = 0; i < 5; i++) { // 关键：把 var 改成 let
    setTimeout(function() {
        console.log(i); // 正确输出：0, 1, 2, 3, 4
    }, 1000);
}

用 IIFE（立即执行函数表达式）创建作用域： 如果你不得不用 var，可以用 IIFE 在每次循环时创建一个新的作用域，把当前的 i 值“锁”住。

for (var i = 0; i < 5; i++) {
    (function(j) { // j 捕获了当前循环的 i 值
        setTimeout(function() {
            console.log(j); // 正确输出：0, 1, 2, 3, 4
        }, 1000);
    })(i); // 立即调用，把当前的 i 传进去作为 j
}