Promise 通过 then 返回新 Promise 实现链式调用,async/await 是其语法糖但提升可读性与控制流表达;并发请求、手动构造 Promise 等场景仍需原生写法,混用时易因遗漏 await 或误用串行导致隐性错误。
Promise 的核心价值不是“替代回调”,而是让 then 可以返回新 Promise,从而自然形成链式调用。比如发起两个 API 请求,第二个依赖第一个的返回结果:
fetch('/api/user')
.then(res => res.json())
.then(user => fetch(`/api/posts?userId=${user.id}`))
.then(res => res.json())
.then(posts => console.log(posts))
.catch(err => console.error(err));
这种写法比嵌套回调清晰,但仍有明显问题:每个 then 都要显式处理上一步的返回值;错误需统一用 catch 捕获,位置靠后容易漏掉中间环节;无法用 return 提前退出流程。
常见踩坑点:
then 中返回 Promise,导致后续 then 接收到 undefined
then 里直接写 console.log 而不返回值,断开链路catch 能捕获所有异步错误——其实只捕获链中抛出的错误,不包括未 await 的独立 Promise是语法糖,但不是“可有可无”的糖。它把 Promise 链的扁平化逻辑,还原成同步代码的阅读节奏。上面的例子改写为 async/await 后:
async function loadUserPosts() {
try {
const userRes = await fetch('/api/user');
const user = await userRes.json();
const postsRes = await fetch(`/api/posts?userId=${user.id}`);
const posts = await postsRes.json();
return posts;
} catch (err) {
console.error(err);
}
}
关键差异在于:
await 会暂停函数执行,但不阻塞主线程——底层仍是 Promise 微任务调度if、for、try/catch 等控制流,不用再拆成多个 then
catch
async,否则 await 会报 SyntaxError: await is only valid in async functions
不是所有场景都适合 async/await。以下情况原生 Promise 更直接:
Promise.all([p1, p2, p3]) 比写三个 await(串行)更高效setTimeout 为 Promise,或处理 EventTarget 一次*件function retry(promiseFn) { ... },传入
setup() 中的 onBeforeMount 钩子)注意:await Promise.all([...]) 是合法的,但别写成 await p1; await p2;——这是串行,性能差很多。
两者可共存,但边界不清晰时会引发隐性 bug:
async 函数里调用另一个 async 函数却不加 await,导致返回的是 Promise 对象而非实际值await 写在循环里(如 for...of),意外造成串行请求,而本意是并发.then() 处理一个 async 函数的返回值,却忘了它已经是 Promise,多套一层 then 导致类型混乱setTimeout 回调中用 await,但没把回调本身标记为 async,导致语法错误最常被忽略的一点:async 函数返回的 Promise 状态,由函数内 return 值或抛出的异常决定,和内部有没有 await 无关。哪怕函数体是空的,返回的也是 pending 状态的 Promise。