Promise 是底层机制，async/await 是其语法糖；日常开发中 async/await 更清晰易维护，但 Promise 构造器在需手动控制 resolve/reject 时不可替代，二者应根据场景混用。
没有“哪种更好”，只有“哪种更合适”——Promise 是底层机制，async/await 是它的语法糖；你绕不开 Promise，但日常写业务逻辑时，async/await 几乎总是更清晰、更易维护。
什么时候必须用 Promise 构造器？
当你需要手动控制异步状态（resolve / reject）时，比如封装一个基于回调的 API、模拟延迟、或实现取消逻辑：
function delay(ms) {
return new Promise(resolve => setTimeout(resolve, ms));
}
// 封装老式 Node.js 回调风格的 fs.readFile
function readFileAsync(path) {
return new Promise((resolve, reject) => {
require('fs').readFile(path, 'utf8', (err, data) => {
if (err) reject(err);
else resolve(data);
});
});
}
常见错误：在 async 函数里还手动写 new Promise 包一层，其实多数时候可以直接 await 已有的 Promise，没必要多套一层。
async/await 真正的优势在哪？
它把嵌套的 .then() 链变成线性代码流，尤其在处理多个依赖关系、条件分支或错误分类时优势明显：
立即学习“Java免费学习笔记（深入）”；
- 错误处理统一用
try/catch，不用分散写.catch() - 可以
await多个独立请求并行执行（配合Promise.all()），也可以串行等待（直接await多次） - 支持
for...of、if、return等同步语义，调试时断点位置更符合直觉
async function fetchUserData(userId) {
try {
const user = await fetch(`/api/users/${userId}`).then(r => r.json());
if (!user.active) throw new Error('User inactive');
const posts = await fetch(`/api/users/${userId}/posts`).then(r => r.json());
const comments = await Promise.all(
posts.map(p => fetch(`/api/posts/${p.id}/comments`).then(r => r.json()))
);
return { user, posts, comments };
} catch (err) {
console.error('Fetch failed:', err.message);
throw err;
}
}
哪些坑容易在 async/await 里踩？
表面像同步，实际仍是异步 —— 这是最大认知偏差：
-
async函数返回的一定是Promise，哪怕你return 42，调用方也必须await或.then()才能拿到值 - 忘记
await某个 Promise，会导致后续代码拿到的是Pending的 Promise 对象，而不是预期数据（常见于循环中漏await） -
await Promise.all([...])失败时会抛出第一个 rejected 的错误，无法知道其他请求是否成功；如需全量结果，得用Promise.allSettled()
兼容性注意：async/await 在 Node.js 7.6+ 和现代浏览器中可用；若需支持 IE 或旧版 Node，仍得靠 Promise + .then()，且要引入 Promise polyfill。
复杂流程里别硬扛 —— 混用才是常态
真实项目中，你不会只用一种风格。比如：
- 用
async/await写主干逻辑 - 用
Promise.race()实现超时控制：await Promise.race([apiCall(), timeout(5000)]) - 用
Promise.allSettled()处理一批非关键请求，避免单个失败中断整体 - 自定义工具函数（如重试、节流）内部仍基于
Promise构造和链式调度
真正难的不是选语法，而是理解「异步操作何时开始、何时结束、失败如何传播」——这个模型在 Promise 和 async/await 下完全一致，只是表达方式不同。
