17370845950

JavaScript执行栈是后进先出的栈结构，用于管理函数调用顺序：函数调用时压入执行上下文，执行完毕即弹出；全局上下文最先入栈、最后出栈；报错信息中的“at”源自栈顶调用链；异步回调需待栈空后由事件循环调度入栈。

JavaScript 执行栈（Call Stack）是引擎用来管理函数调用顺序的机制，它是一个后进先出（LIFO）的栈结构，记录当前正在执行以及等待执行的函数。理解它，关键在于明白“谁在运行、谁在等、谁该退场”。

执行栈怎么形成？

每当一个函数被调用，JS 引擎就会把它的执行上下文（Execution Context）压入执行栈；函数执行完毕，就从栈顶弹出。全局代码也对应一个全局执行上下文，它最先入栈、最后出栈。

• 代码从上到下解析，但只有遇到函数调用才会触发入栈
• 同步代码会连续入栈、出栈；异步回调（如 setTimeout 回调）不直接入当前执行栈，要等调用时才入
• 栈顶永远是当前正在运行的函数

看个简单例子就清楚了

（下面代码运行时执行栈的变化）

function foo() { console.log('foo'); }
function bar() { foo(); }
bar();

过程如下：

• 全局上下文入栈 → 栈：[Global]
• 调用 bar() → 栈：[Global, bar]
• bar 内部调用 foo() → 栈：[Global, bar, foo]
• foo 执行完 → 弹出 → 栈：[Global, bar]
• bar 执行完 → 弹出 → 栈：[Global]
• 全局脚本结束 → 栈空

报错信息里的 "at ..." 是怎么来的？

当你看到 Uncaught TypeError: Cannot read property 'x' of undefined at foo (script.js:3:5)，这个 “at foo” 就是执行栈的快照——JS 引擎按栈从顶到底列出最近几个调用位置，帮你定位错误发生时函数是怎么一层层调过来的。

• 栈越深，嵌套调用越多，排查时越要从最顶上那个函数开始看
• 递归没设好退出条件，栈会不断增长，最终触发 RangeError: Maximum call stack size exceeded

执行栈和异步、事件循环的关系

执行栈只管同步任务。定时器、事件监听、Promise 回调这些异步逻辑，由 Web API 处理完成后，会把回调函数放入任务队列（Task Queue 或 Microtask Queue）。只有当执行栈为空时，事件循环（Event Loop）才会从中取出一个回调，压入执行栈执行。

• 执行栈清空是触发回调执行的前提
• 微任务（如 Promise.then）会在每次栈清空后、下一个宏任务前全部执行完
• 所以 setTimeout(() => console.log(1)); Promise.resolve().then(() => console.log(2)); 输出是 2、1

基本上就这些。执行栈不复杂，但它是理解 JS 同步执行模型、调试报错、搞懂异步时机的底层支点。