Async/Await 是 Promise 的语法糖，async 函数必返回 Promise，await 仅在 async 内部有效，会将后续逻辑注册为微任务，需用 try/catch 显式处理错误，避免与 .then() 混用。

Async/Await 是 JavaScript 中处理异步操作的语法糖，本质是 Promise 的封装。它不改变异步本质，但让 async 函数内部的异步调用看起来像同步代码——前提是理解它怎么“伪装”、以及哪里会突然“露馅”。

async 函数返回值永远是 Promise

哪怕你写 return 42，实际返回的是 Promise.resolve(42)；如果抛错，等价于 Promise.reject(err)。这意味着：

• 调用 async 函数后，必须用 await、.then() 或 .catch() 处理结果，不能直接取值
• await 只能在 async 函数内部使用，顶层 await 仅在 ES Module（如 type="module" 的 script 或 Node.js 的 .mjs 文件）中合法
• 如果你在 async 函数里 return Promise.resolve("ok")，外面 await fn() 拿到的是 "ok"，不是那个 Promise 实例

await 会暂停执行，但不会阻塞线程

await 看起来像“停住”，其实是把后续逻辑注册为 Promise 的微任务（microtask），然后让出主线程控制权。常见误判场景：

• 多个 await 串行执行（如 await a(); await b(); await c();）——它们是严格顺序的，前一个没 resolve，后一个根本不会开始
• 想并行执行？得用 Promise.all([a(), b(), c()])，再 await 它，而不是对每个调用加 await
• await 后面如果不是 Promise，JavaScript 会自动包装成 Promise.resolve(...)，所以 await 123 是合法的，但毫无意义

错误处理必须显式覆盖，try/catch 不是可选项

await 遇到被 reject 的 Promise，会直接抛出异常，中断后续语句。没有 try/catch 就等于把错误甩给调用栈上层——而上层很可能没准备接住。

立即学习“Java免费学习笔记（深入）”；

async function fetchUser() {
  try {
    const res = await fetch('/api/user');
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return await res.json();
  } catch (err) {
    console.error('获取用户失败:', err.message);
    throw err; // 不要静默吞掉，除非你真有业务理由
  }
}

• catch 块能捕获 await 表达式中所有 reject 和同步抛出的错误（比如 JSON.parse() 报错）
• 不要只靠 .catch() 在调用处兜底：函数内部该校验状态码、该处理空响应，就得在内部做，避免错误穿透多层
• finally 块可用于清理（如关闭 loading 状态），但它不接收异常值，也不能修改返回结果

和 Promise.then() 混用时，执行时机容易混淆

混用 await 和 .then() 很危险，尤其在嵌套或链式调用中。下面这段代码的输出顺序常让人困惑：

async function demo() {
  console.log(1);
  await Promise.resolve().then(() => console.log(2));
  console.log(3);
}
demo(); // 输出：1 → 2 → 3

这是因为 .then() 回调属于微任务，而 await 后的代码也是微任务——但它们排队顺序受 Promise 创建和 resolve 时机影响。真实项目中应统一风格：

• 优先用 await + try/catch，语义清晰、调试友好
• 需要组合多个 Promise（如 race、allSettled）时，直接用静态方法，别硬套 await
• 避免在 await 表达式里再写 .then()，那相当于“套娃式微任务”，可读性和错误定位成本陡增

Async/Await 简洁的前提，是你清楚每一处 await 背后都有一个 Promise 在驱动，且它的生命周期完全不受函数作用域“暂停”幻觉的影响。最常出问题的地方，从来不是语法写错，而是忘了它只是糖，不是魔法。