JavaScript事件循环中，调用栈清空后事件循环才从任务队列取任务执行；微任务优先于宏任务，且每次清空全部微任务；setTimeout即使设为0ms也需等待同步代码及微任务执行完毕。
调用栈和任务回调不是两个孤立概念，而是运行时协同工作的底层搭档：调用栈管理同步执行流的“当下”，任务回调则承载异步操作的“将来”，二者通过事件循环紧密咬合。
调用栈决定回调何时能真正执行
JavaScript 引擎只在调用栈完全清空后，才从任务队列中取出下一个回调执行。这意味着：
- 哪怕 setTimeout 设为 0ms，它的回调也必须等所有同步代码（包括深层嵌套函数）执行完毕、栈彻底弹空后才入栈
- 一个耗时长的同步函数（如密集计算或深递归）会阻塞整个事件循环，导致所有宏任务和微任务延迟执行
- 递归过深引发栈溢出时，事件循环根本无法继续，后续任何回调都失去执行机会
回调注册本身不进调用栈，但触发时一定生成新栈帧
调用 setTimeout 或 Promise.resolve().then() 这些 API 时，只是把回调函数存入对应队列，并不会立即创建栈帧；只有当事件循环把它推入调用栈那一刻，才分配栈帧、压入执行上下文。
- Promise.then 的回调属于微任务，会在当前同步任务结束、栈清空后立刻执行——它会新建栈帧，但生命周期极短
- setTimeout 回调是宏任务，要等到本轮微任务全部处理完、可能还经历一次渲染后，才进入下一轮事件循环并压栈
- 同一个回调函数被多次注册（如多个 then），每次触发都会生成独立栈帧，互不影响
栈深度直接影响回调调度的稳定性
调用栈并非无限资源。V8 在 Chrome 中默认栈空间约 984KB，Node.js 约 1.5MB。一旦超出：
- 同步递归直接崩溃，回调队列里的任务永远没机会执行
- 即使没有递归，大量嵌套函数调用也会快速消耗栈空间，降低可容纳的并发回调数量
- 某些异步库（如深层链式 Promise）若内部实现不当，可能隐式加深调用栈，放大风险
调试时需同时观察栈与队列状态
仅看调用栈可能误判问题根源。例如一个“卡住”的 UI，实际原因可能是：
- 调用栈里正执行一个未完成的同步任务（如死循环），导致事件循环无法推进
- 微任务队列被无限 Promise 链填满，不断新增回调、永不退出本轮循环
- 宏任务堆积（如高频 setInterval），但因主线程长期被占用而无法轮到它们
Chrome DevTools 的 Performance 面板可同时捕获调用栈深度、任务类型分布和事件循环延迟，是定位这类耦合问题的关键工具。
