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 在驱动，且它的生命周期完全不受函数作用域“暂停”幻觉的影响。最常出问题的地方，从来不是语法写错，而是忘了它只是糖，不是魔法。
