Promise 通过 then 返回新 Promise 实现链式调用，async/await 是其语法糖但提升可读性与控制流表达；并发请求、手动构造 Promise 等场景仍需原生写法，混用时易因遗漏 await 或误用串行导致隐性错误。
Promise 怎么串起多个异步操作
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
async/await 真的只是语法糖吗
是语法糖，但不是“可有可无”的糖。它把 Promise 链的扁平化逻辑，还原成同步代码的阅读节奏。上面的例子改写为 async/await 后：
立即学习“Java 免费学习笔记（深入）”；
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
什么时候还该用 Promise 原生写法
不是所有场景都适合 async/await。以下情况原生 Promise 更直接：
- 并发请求：用
Promise.all([p1, p2, p3])比写三个await（串行）更高效 - 需要手动构造 Promise：比如封装
setTimeout为 Promise，或处理EventTarget一次性事件 - 作为类型提示或 工具 函数入参：如
function retry(promiseFn) {……}，传入的是函数而非已执行的 Promise - 某些库 API 明确要求返回 Promise 实例（如 Vue 的
setup()中的onBeforeMount钩子）
注意：await Promise.all([……]) 是合法的，但别写成 await p1; await p2;——这是串行，性能差很多。
混用 Promise 和 async/await 容易出什么错
两者可共存，但边界不清晰时会引发隐性 bug：
- 在
async函数里调用另一个async函数却不加await，导致返回的是 Promise 对象而非实际值 - 把
await写在循环里（如for……of），意外造成串行请求，而本意是并发 - 用
.then()处理一个async函数的返回值，却忘了它已经是 Promise，多套一层then导致类型混乱 - 在
setTimeout回调中用await，但没把回调本身标记为async，导致语法错误
最常被忽略的一点：async 函数返回的 Promise 状态，由函数内 return 值或抛出的异常决定，和内部有没有 await 无关。哪怕函数体是空的，返回的也是 pending 状态的 Promise。
