await仅在async函数内有效，异步回调中需显式声明为async；其暂停时机取决于Promise状态与事件循环，pending时让出执行权，fulfilled/rejected时立即继续。
await 不会在异步回调中“自动生效”——它只在 async 函数内部起作用，且执行流优先级由 Promise 状态和事件循环阶段共同决定。
await 只在 async 函数内有效
JavaScript 中 await 是语法关键字，不是函数也不是方法。它只能出现在被 async 修饰的函数体内。如果写在普通回调（如 setTimeout、Promise.then、事件监听器）中，会直接报错 SyntaxError: await is only valid in async functions。
常见错误示例：
setTimeout(() => {
const data = await fetch('/api'); // ❌ 语法错误：不在 async 函数中
}, 100);
正确写法是把回调本身定义为 async 函数，或在外层包裹 async 函数：
立即学习“Java免费学习笔记（深入）”；
- 用
async () => {}定义回调（适用于then、setTimeout等） - 把异步逻辑提取到独立的
async函数中，再传入回调位置
await 的暂停点发生在 Promise pending 阶段
执行到 await promise 时，JS 引擎会检查该 Promise 当前状态：
- 若 Promise 已
fulfilled或rejected（即已 settle），await立即解包值并继续同步执行后续语句（不挂起） - 若 Promise 仍为
pending，当前 async 函数暂停，控制权交还事件循环，等待该 Promise 变为 settled 后，再从暂停处恢复（在 microtask 队列中调度）
这意味着 await 的“等待”不是阻塞线程，而是让出执行权，其恢复时机取决于 Promise 的 resolve/reject 时间点与 microtask 队列的调度顺序。
在嵌套回调中 await 的实际执行顺序
例如以下代码：
async function outer() {
console.log('A');
setTimeout(async () => {
console.log('B');
await new Promise(r => setTimeout(r, 0));
console.log('C');
}, 0);
await Promise.resolve();
console.log('D');
}
outer();
输出为：A → D → B → C。原因如下：
-
console.log('A')同步执行 -
setTimeout(..., 0)将回调推入 task 队列（宏任务） -
await Promise.resolve()立即完成，触发 microtask，接着执行console.log('D') - 本轮事件循环结束，进入下一轮：执行 setTimeout 回调（宏任务），打印
B - 回调内
await new Promise(...)创建一个 pending Promise，暂停 async 回调，等setTimeout(r, 0)触发 resolve 后，将console.log('C')推入 microtask 队列，随后执行
可见，await 在回调中的行为完全遵循事件循环规则，不改变回调本身的宏/微任务分类。
替代方案：避免在回调中滥用 await
频繁在回调里写 async () => {... await ...} 容易导致执行流难以追踪。更清晰的做法包括：
- 用
Promise链代替嵌套回调（如.then().catch()） - 将回调逻辑封装为独立
async函数，显式调用 - 使用
for await...of处理可迭代的异步序列 - 对定时类操作，考虑
new Promise(r => setTimeout(r, ms))转为 Promise，再 await
核心原则：让 await 出现在语义明确、可预测的 async 函数作用域中，而非散落在各类回调里。
