setTimeout(fn, 0) 不会立即执行，因为它将回调推入宏任务队列，必须等待当前同步代码及所有微任务执行完毕后才执行。
setTimeout(fn, 0) 不是“跳过异步”，而是“跳过计时”——它仍会进宏任务队列，必须等同步代码和所有微任务跑完才执行。
为什么 setTimeout(fn, 0) 不等于立即执行
JavaScript 引擎在遇到 setTimeout(fn, 0) 时，并不会把 fn 插入当前调用栈，而是立即触发“计时器初始化算法”，将 fn 封装为一个新宏任务，压入宏任务队列末尾。这意味着：
- 它不会打断正在运行的
for循环、递归或任何同步逻辑 - 即使主线程此刻空闲，它也得排队，不能插队到
Promise.then()前面 - 如果当前微任务队列里有 10 个
queueMicrotask或Promise.resolve().then()，它得等全部清空后才轮到 - 浏览器规范（HTML Standard）还规定：嵌套调用
setTimeout超过 5 次且 delay
对比微任务：为什么 Promise.then() 总比 setTimeout(fn, 0) 先执行
关键差异在于调度层级：Promise.then() 回调属于微任务，而 setTimeout 无论 delay 多小，都属于宏任务。事件循环的执行顺序是固定的：
- 执行一个宏任务（比如当前脚本）
- 清空整个微任务队列（所有
Promise.then、queueMicrotask） - 渲染（可选）
- 取下一个宏任务（这时才轮到
setTimeout(fn, 0)）
所以这段代码：
console.log('start');
setTimeout(() => console.log('timeout'), 0);
Promise.resolve().then(() => console.log('promise'));
console.log('end');
输出一定是：start → end → promise → timeout。
常见误用场景与实际影响
很多人用 setTimeout(fn, 0) 是为了“让出主线程”，但它不是万能解耦方案，容易踩坑：
- 在 React 中滥用它来绕开 state 更新批次（比如
setState后立刻读取 DOM），结果发现 DOM 还没更新——因为setTimeout的宏任务要等 React 自身的微任务（如useEffect清理、更新提交）之后才执行 - 连续写多个
setTimeout(fn, 0)，期望它们按顺序快速执行，但实际每个都会被压入队列末尾，中间可能插入其他宏任务（如用户点击、requestIdleCallback） - 在长耗时同步函数中调用它，比如
sleep(10000)后再setTimeout(..., 0)，那回调真得等 10 秒后才进队列，更别说执行了
什么情况下该用 setTimeout(fn, 0)，什么情况下不该
它适合明确需要“下一宏任务周期执行”的场景，而不是“尽快执行”。判断依据很实在：
- ✅ 适合：强制将 DOM 操作延迟到渲染后（比如读取
offsetHeight前确保样式已计算）、避免阻塞主线程的简单分片（for循环拆成每 1000 项一个setTimeout） - ❌ 不适合：替代
Promise.then做链式响应、等待 React 状态更新完成、实现精确时间控制（它不精准）、解决竞态条件（它不提供原子性） - ⚠️ 注意：现代开发中，
queueMicrotask更轻量、更可控，若只需“本轮最后执行”，优先用它而非setTimeout(fn, 0)
真正容易被忽略的是：它的“零延迟”只承诺不计时，不承诺不排队；而队列长度、微任务积压、浏览器节流策略，都会让它实际执行时机飘忽不定。
