setTimeout调用栈：你真的懂它的执行顺序吗？
前端开发中，我们经常用 setTimeout 延迟执行一段代码。比如点击按钮后等两秒再弹提示，或者防止用户频繁触发某个操作。但有时候你会发现，明明写了 setTimeout(fn, 0)，fn 却没有立刻执行——这背后其实是调用栈和事件循环在起作用。
调用栈是什么？
你可以把调用栈想象成一个叠盘子的架子。每次函数被调用，就往上面放一个盘子；函数执行完，就把盘子拿走。当前正在执行的函数在最顶端，其他函数依次往下堆。
比如有这样一段代码：
function a() {
b();
}
function b() {
c();
}
function c() {
console.log('c 执行了');
}
a();执行时，调用栈的变化是：a → a,b → a,b,c → a,b → a → 空。c 执行完就出栈，回到 b，b 执行完再回到 a，直到全部清空。
setTimeout 怎么影响调用栈？
关键来了：setTimeout 并不会直接进入调用栈。它只是一个“预约”。当你写 setTimeout(fn, 0)，其实是告诉浏览器：“等会儿把 fn 放进任务队列，等主线程空了再执行”。
来看个例子：
console.log('开始');
setTimeout(() => {
console.log('延时任务');
}, 0);
console.log('结束');输出顺序是：
'开始'
'结束'
'延时任务'
即使延时设为 0，回调也不会马上执行。因为它要等当前脚本运行完毕，调用栈清空后，事件循环才会从任务队列里取出 setTimeout 的回调，推入调用栈执行。
实际场景中的表现
你在写一个加载动画时，可能这样处理：
showLoading();
setTimeout(() => {
loadData(); // 模拟耗时请求
hideLoading();
}, 0);但发现 loading 动画根本没显示出来。原因就是：虽然 setTimeout 设为 0，但浏览器还没来得及渲染 loading 状态，主线程就被阻塞了。真正的解决办法是确保 UI 更新有机会先渲染：
showLoading();
setTimeout(() => {
loadData();
hideLoading();
}, 16); // 给浏览器留点时间或者更稳妥地使用 Promise 或 requestAnimationFrame 来协调时机。
别把 setTimeout 当同步工具
有些人想用 setTimeout 把复杂计算拆开，避免页面卡顿。思路是对的，但要注意：它只是把任务扔到下一轮事件循环，并不能缩短总耗时。如果连续塞很多 setTimeout 回调，反而会让任务队列堆积，延迟更严重。
真正提升效率的做法是结合分片处理和合理的异步调度，让主线程有喘息机会，而不是盲目依赖 setTimeout(0)。
理解 setTimeout 和调用栈的关系，能帮你写出更可靠的异步逻辑，也能避开那些“为什么我的代码不按顺序执行”的坑。