JavaScript执行栈是后进先出的栈结构，用于管理函数调用顺序：函数调用时压入执行上下文，执行完毕即弹出；全局上下文最先入栈、最后出栈；报错信息中的“at”源自栈顶调用链；异步回调需待栈空后由事件循环调度入栈。
JavaScript 执行栈（Call Stack）是引擎用来管理函数调用顺序的机制，它是一个后进先出（LIFO）的栈结构，记录当前正在执行以及等待执行的函数。理解它，关键在于明白“谁在运行、谁在等、谁该退场”。
执行栈怎么形成？
每当一个函数被调用，JS 引擎就会把它的执行上下文（Execution Context）压入执行栈；函数执行完毕，就从栈顶弹出。全局代码也对应一个全局执行上下文，它最先入栈、最后出栈。
- 代码从上到下解析，但只有遇到函数调用才会触发入栈
- 同步代码会连续入栈、出栈；异步回调（如 setTimeout 回调）不直接入当前执行栈，要等调用时才入
- 栈顶永远是当前正在运行的函数
看个简单例子就清楚了
（下面代码运行时执行栈的变化）
function foo() { console.log('foo'); }
function bar() { foo(); }
bar();
过程如下：
立即学习“Java免费学习笔记（深入）”；
- 全局上下文入栈 → 栈：[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 同步执行模型、调试报错、搞懂异步时机的底层支点。
