async/await本质是promise与生成器协同工作的语法糖：async函数自动返回promise并封装结果，await通过暂停/恢复机制配合微任务调度等待promise完成。
async/await 的本质，是 Promise 与生成器（Generator）协同工作的结果。它不是凭空出现的新机制，而是把 Generator 的暂停/恢复能力 + Promise 的状态管理能力，封装成更简洁、更易用的语法。
async 函数：自动包装 Promise 的生成器外壳
声明一个 async 函数，等价于定义了一个返回 Promise 的函数，且内部逻辑可被“暂停”。它的返回值无论是什么，都会被自动包裹进 Promise.resolve()；若抛错，则转为 Promise.reject()。这层包装，让函数天然具备异步可组合性。
- 没有 return → 返回 Promise.resolve(undefined)
- return 123 → 返回 Promise.resolve(123)
- throw new Error('fail') → 返回 Promise.reject(...)
await 表达式：在生成器中调度 Promise 的“暂停键”
await 不是阻塞线程，而是在 async 函数（即 Generator 实例）执行到此处时，主动交出控制权。它的行为分两步：
- 对右侧表达式求值；如果结果不是 Promise，就用 Promise.resolve() 包一层
- 若该 Promise 还未完成，函数暂停，当前上下文保存；待 Promise settle 后，将后续代码作为微任务推入队列，等待下一轮事件循环执行
这个“暂停→等待→恢复”的流程，正是 Generator 的 yield + 自动执行器（如 co 库早期做法）与 Promise.then 的融合体现。
底层转换：Babel 等工具如何还原它
现代编译器（如 Babel）会把 async/await 转译为 Generator + 自执行器的形式。例如：
async function foo() {const a = await p1;
const b = await p2;
return a + b;
}
会被展开为类似 Generator 函数 + 递归调用 next() 并链式处理 Promise.then 的结构——每一次 await 对应一次 yield，每一次 resolve 触发下一次 next()。
为什么说它“不是纯 Generator 实现”，但又“离不开 Generator 思想”？
ES 规范并未规定 async/await 必须用 Generator 实现；V8 引擎内部用的是更高效的字节码调度机制。但其语义模型完全继承自 Generator：可暂停、可恢复、支持上下文保持。所以开发者理解它，最直观的路径仍是 Generator + Promise 的协作范式——这也是所有权威资料一致强调的核心逻辑。
