async函数异常处理与简洁性需依“错误是否必须当场响应”决策：该catch就catch，该抛就抛，该兜底就兜底；关键在错误语义清晰、责任明确，而非单纯删减try/catch。
async 函数异常处理和代码简洁之间不是非此即彼的选择，而是需要围绕“错误是否必须当场响应”来判断——该 catch 就 catch，该抛就抛，该统一兜底就统一兜底。关键不在写不写 try/catch，而在每处错误的语义是否清晰、责任是否明确。
哪里必须用 try/catch 包裹 await
当 await 后的操作失败时，你希望立刻做针对性处理（比如重试、降级、提示用户），且后续逻辑依赖这个结果是否成功，就必须用 try/catch。
- API 请求失败后展示友好提示，并停止后续流程
- 读取本地存储失败时 fallback 到默认配置
- 解析 JSON 出错时记录日志并返回空数据，而非让整个函数崩溃
这类场景下，try/catch 不是冗余，而是把错误处理逻辑和业务逻辑写在同一作用域，可读性反而更高。
哪里不该为简洁而省略错误捕获
看似可以省略 try/catch 的地方，往往藏着静默失败风险：
立即学习“Java免费学习笔记（深入）”；
- 循环中 await 每个请求却没加 try/catch → 一个失败就中断整个循环，且无任何反馈
- 多个 await 串行调用，中间任一环节 reject → 后续代码不执行，但控制台只报 unhandled promise rejection
- return Promise.reject(...) 而非 await Promise.reject(...) → 错误不会被当前 try/catch 捕获，而是变成外部调用者的未处理 rejection
这些都不是代码“不够简洁”的问题，而是错误流没被显式定义，容易导致线上问题难以定位。
用结构化方式替代重复 try/catch
如果大量 async 函数都需要类似错误处理（如统一打点、自动重试、转业务错误码），硬写 try/catch 会拉低可维护性。这时可封装成工具函数或自定义 Hook：
- 返回 [error, data] 元组的 safeAwait：const [err, user] = await safeAwait(fetchUser())
- 带重试与兜底的 fetch 封装：await fetchWithRetry('/api/order', { maxRetries: 2 })
- 组件级错误边界配合 useAsync：让 UI 层统一接管 loading/error 状态
这类抽象不增加调用方复杂度，反而让主逻辑更干净，同时保证错误不漏、行为一致。
全局兜底不能代替局部处理
window.addEventListener('unhandledrejection') 或 process.on('unhandledRejection') 是最后一道防线，用于捕获漏网的 rejected Promise，但它无法告诉你“哪个接口在什么条件下失败了”，也无法触发 UI 反馈或业务补偿。
- 它适合上报监控、告警，不适合替代 try/catch 做功能恢复
- 一旦依赖全局兜底来“掩盖”局部缺失的错误处理，代码就进入“看起来能跑，出问题难查”的状态
- 真正健壮的 async 函数，应该既能在局部可控范围内处理已知错误，又能让未知错误浮出水面供排查
简洁不是删掉错误处理，而是让错误流透明、可预测、可测试。
