async/await 是编译器基于状态机实现的语法糖，每个 async 函数运行时被转为隐式状态机；优化关键在于减少无意义 await、拆分长链为可组合单元、避免深度嵌套与递归式 await。
async/await 本身不是用来“实现”状态机的工具，而是编译器或引擎基于状态机机制自动支撑的语法糖。优化复杂状态机逻辑的关键，在于理解它背后的执行模型，并针对性地减少状态切换开销、避免冗余挂起、合理组织控制流。
看清 async 函数本质：它已是状态机
每个 async 函数在运行时都会被 JavaScript 引擎（如 V8）转换为一个隐式状态机——每次 await 都对应一次状态保存与恢复。你写的代码：
async function loadUserThenProfile(id) {
const user = await fetch(`/users/${id}`);
const profile = await fetch(`/profiles/${user.id}`);
return { user, profile };
}
实际等价于一个带 state 字段、局部变量缓存、awaiter 检查和 MoveNext 跳转的状态对象。不需要手动写状态机，但必须意识到：每一次 await 都是一次潜在的上下文保存 + 事件循环让出 + 后续回调调度。
减少无意义的状态挂起
连续 await 并不总是必要。若后续操作不依赖前序结果，强行串行会人为增加状态切换次数，拖慢整体执行。常见误用：
立即学习“Java免费学习笔记（深入）”；
- 对独立接口逐个 await，而非并发发起
- 在循环中对每个 item 单独 await，导致 N 次状态暂停
- await 一个已 resolve 的 Promise（如 Promise.resolve(1)），徒增状态机开销
优化方式：用 Promise.all 替代串行 await；对已知同步值，直接返回，不包 Promise；对确定完成的任务，避免 await 包裹。
拆分长链为可组合的异步单元
当业务流程包含多个阶段（如鉴权 → 获取配置 → 加载数据 → 渲染 → 埋点），不要堆在一个巨型 async 函数里。应拆成小而专注的 async 函数，再按需组合：
- 每个函数只负责单一职责，状态机更轻量
- 便于复用、测试和条件跳过（如缓存命中时跳过 fetch）
- 可配合 Promise.race 实现超时控制，或用 .catch() 统一兜底，避免层层 try/catch
例如：把“加载用户+头像+权限”拆为 loadUser()、loadAvatar()、checkPermission()，再根据依赖关系决定是并行还是顺序调用。
慎用深度嵌套与递归式 await
深层嵌套（如 async 函数内调用另一个 async 函数，再调用第三个）会拉长状态机调用栈，增加错误追踪难度，也放大上下文切换成本。递归式 await（如分页拉取直到结束）若未设终止条件或未做节流，容易触发栈溢出或内存堆积。
建议：
- 用 while 循环 + await Promise.all 处理分页，而非递归调用
- 对可能深链的流程，加最大重试次数和延迟退避
- 开启 Chrome DevTools 的 “Async stack traces”，定位真实挂起点
