我们先梳理几个关键概念：await 挂起的是异步函数的执行上下文，而非线程——这一区别至关重要。JavaScript 采用单线程模型运行，根本不存在可挂起的线程概念。此外，await 只能在 async 函数内使用，它等待的是一个 Promise 或 thenable 对象，后续代码会被当作微任务调度，绝不会阻塞主线程。
说得更直白一点：await 不会“冻结”整个线程，它只是让当前函数的执行暂时暂停，将控制权交还给事件循环，从而让其他任务有机会运行。很多初学者误以为“await 挂起线程”，这其实是一个常见的误解，因为 JavaScript 并没有真正的线程概念（主线程不存在多线程抢占）。
await 只能在 async 函数内部使用
这是语法层面的硬性规定。如果在普通函数或顶层作用域中直接写 await somePromise()，编译器会立即抛出语法错误。
- 正确用法：
async function foo() { await fetch('/api'); } - 错误用法：
function bar() { await fetch('/api'); }（立即报 SyntaxError） - 补充说明：顶层
await仅在 ESM 模块作用域下才被允许使用，不等于在普通脚本中可以随意书写
await 等待的是“thenable”对象，本质是 Promise 状态流转
await 后面的表达式会被自动调用 Promise.resolve() 进行包装。它真正等待的是这个 Promise 进入 fulfilled 或 rejected 状态。
await 123→ 等价于await Promise.resolve(123)，实际上会立即继续往下执行await fetch(url)→ 等待网络响应返回 Response 对象await new Promise(r => setTimeout(r, 1000))→ 等待 1 秒后 Promise 状态变为 fulfilled，然后继续执行
await 之后的代码会被放入微任务队列，而非立即执行
这一点尤其值得关注。当 await 后面的 Promise 完成之后，其后续代码并不会像同步代码那样立刻执行，而是会被当作一个微任务（microtask）来调度，等到当前所有同步代码执行完毕、在下一次宏任务（如 setTimeout 的回调）之前才会被执行。
- 换句话说：
await不会阻塞浏览器渲染，也不会干扰用户交互响应，UI 依然可以流畅运行 - 多个
await串行执行时，每一个await都会暂时“暂停”当前函数的执行体，但并不会冻结整个 JavaScript 引擎 - 来看一个示例：
await a(); console.log('1'); await b(); console.log('2');这里的执行顺序是——'1' 一定在 a() 返回的 Promise 变成 fulfilled 之后才打印，'2' 同理，保证严格的先后顺序
避免常见误用：不要用 await 包裹非 Promise 值做“伪等待”
例如 await setTimeout(...) 这种做法完全无效——setTimeout 返回的是一个定时器 ID（数字），并非 Promise，await 遇到这个数字会立即解包并继续往下走，根本达不到延迟执行的效果。
- 正确的延迟写法：
await new Promise(r => setTimeout(r, 1000)); - 错误示例：
await setTimeout(() => {}, 1000);（完全不起作用） - 注意：对一个已经 resolve 的 Promise 使用
await并不会带来性能损失，但如果对纯粹的同步值（如字符串、字面量对象）使用await，则完全没有必要
理解 await 的本质——它是用来暂停函数执行、交还控制权、等待 Promise 状态确定后再恢复执行——这一认知比单纯记住“挂起线程”更准确且实用。
