async/await是promise的语法糖，不改变其执行机制，仅提升可读性与调试体验；它支持try/catch错误处理、清晰调用栈、灵活控制并发，但需注意串行/并发逻辑设计。
async/await 是 Promise 的语法糖，不是替代品
async/await 本身不改变 Promise 的执行机制，它只是让基于 Promise 的异步代码写起来更像同步代码。函数加 async 关键字后，返回值自动被 Promise.resolve() 包裹；await 只能在 async 函数内使用，且只能等待 thenable 对象（包括原生 Promise）。它没解决 Promise 的本质问题（比如无法取消、错误需靠 catch），但大幅降低了心智负担。
错误处理更符合直觉：try/catch 可捕获 await 抛出的异常
用 Promise 链时，.catch() 容易漏写或位置不对，尤其嵌套多层时；而 await 后的错误可直接用 try/catch 捕获，和同步代码一致。注意：未被 try/catch 包裹的 await 错误仍会变成 rejected Promise，该行为和 throw 一样。
-
await一个 rejected Promise 等价于throw该 rejection 值 - 多个
await可共用一个try/catch，避免重复写.catch() - 想“静默失败”需显式包裹：
try { await fetch('/api'); } catch (e) { /* 忽略 */ }
调试体验明显更好：call stack 更清晰，断点更自然
Promise 链中打 debugger 或设断点，执行流会跳进 microtask 队列，调用栈常显示 Promise.then 或匿名函数，难以追溯原始调用路径。async/await 编译后虽仍是 Promise，但现代引擎（V8、SpiderMonkey）做了优化，支持在 await 行暂停，并保留外层函数上下文。
- Chrome 和 VS Code 中，可在
await行直接打断点，单步进入下一行（而非跳进then回调） - 错误堆栈里会显示
async function foo而非一堆Promise.then - 注意：若 await 的 Promise 是由
setTimeout或new Promise手动创建且未加console.trace()，堆栈仍可能丢失源头
控制并发比 Promise.all() 更灵活，但别滥用 await 串行化
很多人误以为 async/await 天然“慢”，其实是写法问题。连续写多个 await 是串行；想并发，仍要靠 Promise.all() 或 Promise.allSettled()。区别在于：async/await 让你更容易混合串行与并发逻辑。
立即学习“Java免费学习笔记（深入）”；
async function loadBoth() {
// ❌ 串行（总耗时 ≈ a + b）
const a = await fetch('/a');
const b = await fetch('/b');
<p>// ✅ 并发（总耗时 ≈ max(a, b)）
const [a, b] = await Promise.all([
fetch('/a'),
fetch('/b')
]);
}- 需要按顺序获取数据（如 token → 用 token 请求资源），就用连续
await - 需要并行请求且任一失败即中断，用
await Promise.all([...]) - 需要并行但不想因某个失败中断其余，用
await Promise.allSettled([...])
真正容易被忽略的是：async/await 不改变事件循环模型，microtask 排队规则照旧；如果你在循环里写 await 却没意识到它阻塞了后续迭代，就可能把本可并发的操作变成严苛串行。
