async/await 的清晰性取决于结构组织而非语法本身；应统一使用 await 链、避免混用 .then()，用 try/catch 划定逻辑单元，并以同步风格书写条件与循环。
async/await 本身不自动带来清晰，关键在于怎么组织它。真正让复杂异步逻辑变清晰的，不是加了 async 和 await，而是用对结构、控制流和错误边界。
统一 await 链，拒绝混合 .then()
常见混乱源头是“一半 async，一半 then”——比如函数内部用了 await，外部调用却写成 getData().then(...)。这保留了 Promise 链的割裂感，变量作用域断开，错误捕获分散。
- 整个调用链都应包裹在 async 函数中，用
await逐行等待 - 避免在顶层或事件回调里直接 .then() 接收 async 函数返回值
- 例如：获取用户后查订单，写成两行
await，而不是getUser().then(u => getOrders(u.id))
用 try/catch 划定逻辑单元
多个依赖步骤（如“拉配置 → 校验 → 初始化服务”）应放在同一个 try 块里，让错误上下文完整、位置明确。
- 一个 try 块覆盖全部相关 await，包括 fetch 失败、JSON 解析出错、业务校验 throw
- 需要差异化处理时，可嵌套 try/catch：外层捕获网络超时，内层捕获数据格式异常
- 不必为每个 await 单独配 catch，也避免“最后一个 .catch 管太宽”或中间漏捕获
把条件和循环写得像同步代码
异步流程常需根据前一步结果分支或重试，这时别硬塞进 Promise 链，直接用 if / for / while：
-
if (user.role === 'admin') await loadAdminPanel()—— 分支一目了然 -
for (const item of list) await uploadItem(item)—— 批量串行清晰可控 while (!success && retry —— 重试逻辑直白不绕
并行请求用 Promise.all，但别滥用
无依赖的请求（如同时拉用户信息、通知数、未读消息）适合并行，但要注意错误传播和粒度控制。
- 用
const [user, stats, msgs] = await Promise.all([fetchUser(), fetchStats(), fetchMsgs()]) - 若某一项失败导致整体 rejected，可改用
Promise.allSettled获取各结果状态 - 避免把有依赖的请求强行塞进 all —— 比如“先登录再拉数据”，必须串行
