调用栈和异步任务间的状态同步机制

调用栈仅追踪同步执行路径，不管理异步状态；异步回调由事件循环调度、任务队列存放、闭包维持作用域，执行时新建上下文入栈。

调用栈本身不与异步任务“同步状态”，它只反映当前正在执行的同步代码路径。异步任务的回调函数在被推入调用栈之前，其执行时机、上下文和状态均由事件循环、任务队列和闭包环境共同决定，而非调用栈主动维护或同步。

调用栈只记录同步执行流

调用栈是纯同步结构，遵循后进先出（LIFO）原则。每当一个函数被调用，它的执行上下文就压入栈顶；返回时立即弹出。它不保存异步任务的中间状态，也不感知定时器是否到期、请求是否响应。哪怕一个 setTimeout 已注册 5 秒，只要回调还没执行，调用栈里就完全“看不见”它。

• 同步代码逐行入栈、出栈，过程清晰可追踪
• 异步操作（如 fetch、setTimeout）一旦发起，控制权立刻交还给主线程，调用栈清空或继续执行后续同步逻辑
• 回调函数只有被事件循环选中并推入调用栈那一刻，才真正进入执行上下文

状态实际靠闭包和作用域维持

异步回调能访问外部变量，并非因为调用栈“记住”了它们，而是依靠 JavaScript 的词法作用域和闭包机制。函数定义时捕获的变量引用，在回调执行时依然有效。

• 例如：let count = 0; setTimeout(() => console.log(count), 100); count = 1; —— 输出 1，不是因为调用栈同步了 count，而是回调函数闭包持有对 count 的引用
• Promise 的 then 回调、async/await 中的 await 后代码，也都依赖作用域链，而非栈帧传递
• 若变量被重新赋值或销毁（如函数退出后局部变量本该释放），但仍有活跃闭包引用，它就会继续存活

事件循环是真正的协调者

调用栈和异步任务之间没有直接通信通道。事件循环才是那个持续观察二者状态的“调度员”：

• 当调用栈为空，事件循环检查微任务队列（如 Promise.then），清空所有微任务后再查宏任务队列（如 setTimeout）
• 它把下一个待执行的回调从队列取出，**新建一个执行上下文**，压入调用栈——此时才开始真正执行
• 这个过程不复用旧栈帧，也不恢复历史栈状态；每次回调都是“干净”的新入口

别被 console.trace() 迷惑

浏览器开发者工具里的 console.trace() 有时显示很长的“调用路径”，容易让人误以为异步调用在延续栈深度。其实这是 DevTools 的增强追踪行为，它会尝试关联异步触发源头（比如哪个 setTimeout 启动了这次回调），并非真实调用栈内容。

• 真实同步栈可用 new Error().stack 查看，你会发现每次异步回调的栈都极短，通常只含回调自身和事件循环入口
• 递归调用的栈会层层累积，而异步链式调用的每个环节栈都是独立、重置的
• 这种设计正是为了防止栈溢出，也是单线程 JS 支持高并发 I/O 的基础