EventLoop 不直接处理 await 暂停点，而是依赖 Promise 状态流转与微任务队列协同：await 将后续代码包装为 then 回调入微任务队列，待当前宏任务结束、微任务清空后恢复执行；async 函数体同步执行至首个 await，之后逻辑以微任务形式延迟执行。
JavaScript 的 EventLoop 并不直接“处理” await 暂停点，而是通过 Promise 状态流转与微任务队列协同配合，让 async 函数在暂停和恢复之间自然衔接。
await 实际上是 Promise + 微任务的语法糖
await 后面表达式一旦求值为一个 Promise（或可 thenable 对象），当前 async 函数就会暂停执行，并把后续代码包装成一个 then 回调，注册进该 Promise 的微任务队列中。EventLoop 在本轮宏任务结束后，会清空微任务队列——这时回调被调用，async 函数才继续执行。
- 不是 JavaScript 引擎“挂起线程”，也没有真正的“协程调度”
- 暂停只是函数控制流的中断，上下文（如变量、执行栈帧）由引擎内部保存（通常在闭包或状态机中）
- 恢复执行的时机，完全取决于所 await 的 Promise 何时 resolve/reject，以及它触发的微任务何时被 EventLoop 执行
async 函数体本身是同步执行到第一个 await 的
定义一个 async 函数时，函数体最开始的部分（直到第一个 await 或函数结束）是同步运行的。此时若返回值未被 await，函数立即返回一个 pending 状态的 Promise。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 例如：
async function f() { console.log('start'); await Promise.resolve(); console.log('end'); }—— 调用f()会立刻打印start，并返回 Promise；end要等微任务执行才打印 - 这意味着 async 函数的“启动开销”极小，真正异步的是 await 后的恢复逻辑
await 后的代码被编译为微任务，不是宏任务
V8（及其他主流引擎）将每个 await 后的语句，编译为类似 promise.then(() => { /* 后续逻辑 */ }) 的形式。这个 then 回调属于微任务，优先级高于 setTimeout、setInterval、I/O 回调等宏任务。
立即学习“Java免费学习笔记（深入）”；
- 哪怕你 await 一个已经 resolve 的 Promise（如
await Promise.resolve(42)），后续代码也不会立刻执行，而是排队进微任务队列，等当前同步脚本执行完再运行 - 多个 await 链式调用，会形成一连串微任务：每个 await resolve 后，都把下一个 await 前的代码作为新微任务入队
await 不会进入事件循环的“等待”阶段
EventLoop 本身没有“等待 await”的机制。它只按规则轮询：执行一个宏任务 → 清空微任务队列 → 下一个宏任务……await 只是让函数主动让出控制权，靠 Promise 驱动后续恢复，而非 EventLoop 主动调度。
- 没有“await 休眠 N 毫秒”这种操作；想延时需显式写
await new Promise(r => setTimeout(r, 100)) - 如果 await 的 Promise 永远不 settle（比如没被 resolve/reject），async 函数就永远卡在那，但 EventLoop 照常运行其他任务
