setTimeout(0)不是立刻执行，而是进入下一轮宏任务队列，需等待当前宏任务及所有微任务执行完毕后才调度；受浏览器最小延迟（≥4ms）、后台节流（可达1000ms）等限制，实际延迟常为5–15ms或更高。
setTimeout(0) 不是“立刻执行”，而是“尽快在下一个宏任务阶段执行”——它必须等完当前宏任务 + 所有微任务，才能排队等待调度。
它不等于同步执行
很多人以为 setTimeout(0) 能绕过异步队列、实现“马上运行”，其实它只是把回调函数放进「下一轮 timers 阶段」的任务队列头部。但这个队列不会被立即处理，必须满足两个前提：
- 当前正在执行的宏任务（比如点击事件处理函数、脚本加载后的顶层代码）已全部结束
- 所有已排队的微任务（Promise.then、queueMicrotask、MutationObserver 回调等）已被清空
微任务会明显拖慢它的时机
即使主线程很快空闲，微任务也会抢占 setTimeout(0) 的执行机会。例如：
console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
// 输出顺序：1 → 4 → 3 → 2
这里 Promise.then 在当前宏任务末尾立即执行，而 setTimeout(0) 的回调要等到下一轮事件循环的 timers 阶段才被取出——中间还可能插入其他宏任务（如用户点击、IO 回调）。
浏览器还有最小延迟限制
根据 HTML 规范，嵌套调用超过 5 层的 setTimeout，浏览器会强制将延迟设为至少 4ms。也就是说，即使你写的是 setTimeout(fn, 0)，实际入队时间也可能被拉长到 4ms 之后，再叠加任务排队耗时，整体延迟常达 5–15ms 甚至更高。
后台标签页还会进一步节流
当页面处于非激活状态（比如切换到其他浏览器标签），Chrome 等主流浏览器会把定时器最小间隔提升至 1000ms。此时 setTimeout(0) 可能等上整整 1 秒才触发，完全失去“快速响应”的意义。
