async/await的核心价值在于降低异步逻辑维护成本：通过线性代码结构、集中错误处理、清晰函数职责和同步式调试体验提升可维护性，但需避免过度串行化、隐式Promise链和嵌套async函数等问题。
async/await 的核心价值不在于“新增能力”，而在于大幅降低异步逻辑的维护成本——它把原本分散在多层回调或嵌套 .then() 中的控制流，收束为线性、可逐行追踪的代码结构。
可维护性提升的关键表现
异步错误处理变得集中且直观：不再需要在每个回调里重复写 if (err) throw err 或 .catch()，而是统一用 try/catch 包裹整个逻辑块，错误堆栈也更贴近真实执行顺序。
函数职责更清晰：一个 async 函数天然表达“一段有先后依赖的异步流程”，无需靠注释或命名（如 fetchThenParseThenSave）来暗示执行关系。
调试体验接近同步代码：断点可以自然停在 await 行，变量作用域连续，Chrome DevTools 的 async stack traces 能准确映射到源码位置，而不是跳进 Promise 内部的微任务队列。
代码复杂度的真实影响因素
async/await 本身不增加运行时复杂度，但可能掩盖设计问题：
- 过度串行化：连续 await 三个无关接口（如 await getUser(); await getProfile(); await getSettings();），实际应并行发起，用 Promise.all() 降低总延迟；
- 隐式 Promise 链：async 函数返回 Promise，若调用方忽略返回值或未处理 reject，错误会静默丢失；
- 嵌套 async 函数：深层调用链（如 A → B → C，每层都 async）会让堆栈变长，不利于定位源头问题，此时应考虑提取公共异步逻辑为独立工具函数。
降低维护负担的实用习惯
保持 await 的语义明确：只用于真正需要等待结果的步骤。例如，日志上报、埋点等非关键路径操作，可用 fire-and-forget 方式（直接调用不 await）避免阻塞主流程。
批量操作优先 map + Promise.all：遍历 ID 列表请求用户数据时，避免 for...of + await，改用 Promise.all(ids.map(id => fetchUser(id)))。
错误边界要前置：在入口级 async 函数中设置统一 try/catch，并记录 error.stack 和上下文（如请求参数、用户 ID），而不是让错误层层上抛再捕获。
避免在循环体内无条件 await：除非业务强依赖前序结果，否则多数场景更适合并发或分批处理。
