async/await 使 try...catch 能自然捕获 await 的 promise rejection，实现集中错误处理；需区分业务与系统错误并分支响应，避免吞错、空 catch，配合 finally 做清理。
async/await 本身不改变 JavaScript 的异常处理机制，但它让 try...catch 能自然覆盖异步操作，大幅降低错误分散、嵌套难读、遗漏 catch 的风险。
用 try/catch 包裹 await 表达式
这是最直接的方式：所有被 await 的 Promise 若 reject，会像同步抛错一样被外层 try...catch 捕获。
- 避免在每个
await后单独写.catch()，逻辑更集中 - 多个异步步骤可共用同一套错误处理逻辑，比如统一日志、降级或重试
- 注意：只捕获被
await的 Promise 的 rejection，未 await 的 Promise 仍需自行处理
区分业务错误与系统错误
实际开发中，有些 rejection 是预期的（如接口返回 401），有些是意外的（如网络中断）。可在 catch 中判断错误类型，做不同响应。
- 后端约定错误结构（如
{ code: 401, message: '登录过期' }），在catch中解析并分支处理 - 对网络类错误（
TypeError、AbortError）可触发重试；对业务码（如code === 403）跳转权限页 - 避免把所有错误都 throw 出去，防止上层重复处理
避免“吞掉”错误
常见误区是写了 try...catch 却没做任何处理，或只 console.log 而不通知用户、不记录日志。
- 即使选择静默处理（如兜底默认值），也建议打点或埋点，便于监控异常率
- 不要在
catch中空 return 或 return undefined，除非明确该场景下无值是合理结果 - 若需继续抛出，用
throw error（保持原错误），或throw new Error(...)封装上下文信息
配合 finally 做清理工作
finally 在 Promise settle（无论 resolve/reject）后执行，适合关闭加载状态、释放资源等。
- 例如：请求前设
loading = true，finally中设为false，确保 UI 总能恢复 - 注意：
finally不接收参数，无法得知是否成功；需结合状态变量或在外层定义标识 - 不推荐在
finally中修改关键业务逻辑，它只负责副作用清理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
