async函数本质是Promise封装，返回Promise且执行仍异步；await仅暂停当前函数执行流，不阻塞线程，依赖事件循环与微任务队列调度。
async 函数本身不会让异步事件“真正同步”，它只是让异步代码的书写和阅读方式更像同步——执行逻辑仍是异步的，依赖事件循环、微任务队列和 Promise 状态流转。
async 函数的本质是 Promise 封装
声明一个 async 函数，等价于返回一个 Promise：
- 函数体内 return 一个普通值（如 return 42），自动包装成 Promise.resolve(42)
- 函数体抛出错误（throw new Error()），等价于 Promise.reject(...)
- 即使函数内部没有 await，也始终返回 Promise，调用后不能直接拿到结果，必须用 .then() 或 await 消费
await 并不暂停线程，只暂停当前 async 函数的执行流
await 后面表达式一旦求值为 Promise，JS 引擎会把后续代码挂起，让出主线程，继续执行其他同步或微任务。等该 Promise settled（fulfilled/rejected）后，再将后续逻辑作为微任务推入队列。
- 它不改变底层耗时：fetch 请求仍要等网络往返，setTimeout 仍要等指定毫秒
- 它不消除排队：多个 await 串行写法，只是按顺序发起异步操作，不是并行加速
- 常见误解：“加了 await 就变快了”——实际只是控制了执行时机，而非压缩延迟
异步事件处理中“看起来同步”的关键机制
比如给按钮绑定 click 事件，内部用 await 处理 API 请求，用户点击后界面不会卡住，但后续逻辑（如更新 UI）会等请求完成才运行：
立即学习“Java免费学习笔记（深入）”；
- 事件回调本身是宏任务，进入执行栈后立即触发 async 函数
- await 导致函数暂停，当前宏任务结束，控制权交还事件循环
- 响应返回后，resolve 触发，await 后代码以微任务形式排队执行（优先级高于 setTimeout）
- 因此视觉上“点击 → 等待 → 更新”，流程清晰，但时间轴上仍是非阻塞的异步链
容易忽略的陷阱：await 不等于顺序保障
多个 await 语句是串行的，但若想并行发起请求，不能简单连写 await；否则第二个请求要等第一个完全结束才开始：
- ❌ 错误写法（串行，总耗时 ≈ t1 + t2）：
const a = await fetch('/api/a');
const b = await fetch('/api/b'); - ✅ 正确写法（并行，总耗时 ≈ max(t1, t2)）：
const [a, b] = await Promise.all([fetch('/api/a'), fetch('/api/b')]);
