调用栈仅追踪同步执行路径，不管理异步状态；异步回调由事件循环调度、任务队列存放、闭包维持作用域，执行时新建上下文入栈。
调用栈本身不与异步任务“同步状态”，它只反映当前正在执行的同步代码路径。异步任务的回调函数在被推入调用栈之前，其执行时机、上下文和状态均由事件循环、任务队列和闭包环境共同决定，而非调用栈主动维护或同步。
调用栈只记录同步执行流
调用栈是纯同步结构，遵循后进先出（LIFO）原则。每当一个函数被调用，它的执行上下文就压入栈顶；返回时立即弹出。它不保存异步任务的中间状态，也不感知定时器是否到期、请求是否响应。哪怕一个 setTimeout 已注册 5 秒，只要回调还没执行，调用栈里就完全“看不见”它。
- 同步代码逐行入栈、出栈，过程清晰可追踪
- 异步操作（如
fetch、setTimeout）一旦发起，控制权立刻交还给主线程，调用栈清空或继续执行后续同步逻辑 - 回调函数只有被事件循环选中并推入调用栈那一刻，才真正进入执行上下文
状态实际靠闭包和作用域维持
异步回调能访问外部变量，并非因为调用栈“记住”了它们，而是依靠 JavaScript 的词法作用域和闭包机制。函数定义时捕获的变量引用，在回调执行时依然有效。
Javascript Sdk
下载
用于 inference.sh 的 JavaScript/TypeScript SDK，可运行 AI 应用、构建代理、集成 150+ 模型。包名：@inferencesh/sdk（npm install），完整 TypeScript 支持。
- 例如：
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 的基础
