async/await是Promise的语法糖，底层依赖then/catch；await暂停async函数执行并交还控制权给事件循环，不阻塞线程；await后非Promise值会被Promise.resolve()包装；错误必须用try/catch捕获，不可链式.catch()；并行应await Promise.all([p1,p2])而非逐个await。
async/await 本质是语法糖，不是新异步模型
它只是 Promise 的封装，底层仍依赖 Promise.prototype.then 和 Promise.prototype.catch。写 async 函数时，JS 引擎会自动把它包装成返回 Promise 的函数；await 则会暂停函数执行，直到右侧的 Promise settled（fulfilled 或 rejected），再继续往下走。
常见误解是“用了 await 就能阻塞线程”——其实不会。JS 仍是单线程、非阻塞的，await 只是让当前 async 函数挂起，把控制权交还给事件循环。
await 后面必须是 Promise，否则会被 Promise.resolve() 包装
这是最容易忽略的隐式转换点。比如：
async function test() {
const a = await 42;
console.log(a); // 42
}
await 42 看似奇怪，但等价于 await Promise.resolve(42)。同理，await null、await {x:1} 都会立刻 resolve。
- 想真正等待某个值？必须显式返回
Promise，比如await fetch(...)、await new Promise(...) - 误写
await someSyncFunction()不报错，但失去了异步意义，还可能掩盖逻辑错误 - 调试时注意：Chrome DevTools 的 “Async Call Stack” 能帮你定位 await 暂停点，比纯 Promise 链更直观
try/catch 是处理 await 错误的唯一推荐方式
await 遇到 rejected Promise 会直接抛出异常，必须用 try/catch 捕获。不能靠 .catch() 链式调用——那会破坏 await 的线性流程。
async function getUser() {
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; // 重新抛出，让调用方决定如何处理
}
}
- 不要写
await promise.catch(...)，这会让错误静默吞掉，且无法在 await 后继续使用返回值 - 多个 await 连续调用时，一个失败会导致后续不执行——符合直觉，但要注意是否符合业务逻辑（比如发两个独立请求，不应互相阻断）
- 若需并行执行，改用
Promise.all([await p1, await p2])❌ 错！应写成await Promise.all([p1, p2])，否则仍是串行
顶层 await 只在模块作用域有效，CommonJS 里不支持
Node.js 14.8+ 和现代浏览器支持顶层 await，但仅限于 ES 模块（type="module" 或 .mjs）。在 require() 加载的 CommonJS 文件中写顶层 await 会报 SyntaxError: await is only valid in async functions an。
- Node.js 中可通过
node --input-type=module执行内联代码，或确保package.json有"type": "module" - Webpack/Vite 等构建工具默认按模块处理，但若配置了
output.libraryType: 'commonjs2'，顶层 await 仍会失效 - 想兼容旧环境？老老实实用
(async () => { ... })()自执行函数包裹
await delay(1000) 之后的代码一定在 1 秒后运行，却忽略了前面还有未 resolve 的 Promise 在排队。async/await 让代码看起来像同步，但调度权始终在事件循环手里。
