async/await底层基于Promise和微任务队列运行：async函数必返回Promise，await将后续代码包装为微任务，在当前宏任务结束后执行；执行上下文决定运行环境，await仅挂起而非销毁它，恢复时仍使用原词法环境。
JavaScript 执行上下文和 async/await 的执行顺序紧密关联，但它们属于不同层级的机制：执行上下文决定“谁在运行、变量在哪找”，而 async/await 的调度依赖事件循环中的微任务队列。理解两者如何配合，才能真正看清代码为什么按那个顺序打印。
执行上下文：函数调用时的“运行环境”
每次函数被调用，JS 引擎都会创建一个新的函数执行上下文，并压入执行栈（Call Stack）。它包含三部分：变量环境（var、function 声明）、词法环境（let、const、函数参数）、this 绑定。全局代码也有一个全局执行上下文。
关键点：
- async 函数被调用时，会立即进入其执行上下文，同步部分（比如 await 之前的所有语句）照常执行；
- await 不会销毁当前执行上下文，而是“挂起”它，等 Promise settled 后再恢复——这个恢复动作发生在微任务阶段，仍使用原来的词法环境和变量绑定；
- 执行上下文栈只管理同步调用链，不直接管理 await 暂停或微任务回调的恢复。
Async 函数返回值与 Promise 封装
所有 async 函数都自动返回 Promise，这是硬性规则，与内部有没有 await 无关。
立即学习“Java免费学习笔记（深入）”；
行为统一如下：
- 函数正常 return 一个值 v → 等价于 Promise.resolve(v)；
- 函数 return undefined 或无 return → 等价于 Promise.resolve(undefined)；
- 函数 throw 错误 → 等价于 Promise.reject(e)；
- 即使函数体只有一行 console.log('hi')，返回的仍是已 resolve 的 Promise。
Await 如何影响执行流
await 并不是“等待完成才继续”，而是把 await 后面的代码（包括后续语句、return、throw）包装成一个微任务回调，注册到微任务队列中。
典型流程：
- 遇到 await 表达式，先求值；若结果是 Promise，就监听它的 settled 状态；
- 当前 async 函数暂停，控制权交还给外层（比如上一个宏任务）；
- 外层同步代码继续执行，直到宏任务结束；
- 引擎清空微任务队列：执行由 await 注册的那个回调（即恢复 async 函数执行）；
- 恢复后，await 表达式得到值（fulfilled 值或抛出 rejection），接着执行后续语句。
完整执行顺序示例解析
看这段代码：
console.log('a');async function foo() {
console.log('1');
await Promise.resolve();
console.log('2');
}
foo();
console.log('b');
输出是：a → 1 → b → 2。原因分步：
- 'a' 是同步代码，在主 script 宏任务中立即执行；
- 调用 foo()，进入其执行上下文，同步执行 console.log('1')；
- 遇到 await Promise.resolve()，Promise 立即 fulfilled，引擎将 console.log('2') 包装为微任务；
- foo 暂停，控制权回到主 script，执行 console.log('b')；
- 主 script 宏任务结束，开始清空微任务队列，执行 console.log('2')。
