async 函数返回 promise，内部 throw 的错误会成为其 rejection reason，await 会将其解包为抛出的 error 实例；错误传递方式包括 try/catch、.catch() 和元组风格返回；建议自定义错误类并增强上下文，避免错误静默丢失。
async 函数本身不自动包装错误，它只是让函数返回一个 Promise；错误是否被包装、如何传递，完全取决于你怎样写内部逻辑和怎样调用它。核心在于：抛出的错误会变成 Promise 的 rejection 原因，而 await 会把这个原因“解包”成 throw 出来的 Error 实例。
错误从 throw 到 Promise rejection 的映射
当你在 async 函数里 throw new Error('xxx')，函数返回的 Promise 状态立即变为 rejected，其 rejection reason 就是这个 Error 实例。这和手动 return Promise.reject(new Error('xxx')) 效果一致。
- throw 同步错误 → Promise 被 reject，reason 是 Error 对象
- await 一个已 reject 的 Promise → 等效于 throw 该 rejection reason
- 未 catch 的错误会逐层向上冒泡，直到被 try/catch 捕获，或触发 unhandledrejection 事件
常见错误传递模式
实际开发中主要有三种主流传递方式，适用不同场景：
- try/catch 显式捕获：适合需要即时响应、做 UI 提示或 fallback 的地方。错误保持原样（Error 实例），可直接访问 message、stack、name 等属性。
-
.catch() 链式捕获：适合 Promise 链末尾统一兜底，或在调用侧处理，比如
fetchData().catch(handleError)。 - 元组风格返回 [error, result]：用高阶函数封装 async 函数，让其始终 resolve，把错误作为第一个元素返回（类似 Go）。这样调用方无需 try/catch，靠判空即可分支处理。
自定义错误包装与分类
原始错误往往信息不足。建议在关键位置主动增强错误上下文：
- 在 fetch 封装层补充 URL、method、status 等字段
- 继承 Error 类创建业务错误类型，如
class ApiError extends Error { constructor(msg, code) { super(msg); this.code = code; } } - 用 instanceof 或 error.name 区分错误类型，避免用字符串匹配
- 对网络超时、4xx/5xx、JSON 解析失败等分别构造不同子类，便于后续策略分流（重试 / 降级 / 上报）
避免错误丢失的实践要点
有些写法会让错误静默消失或难以追踪：
- 不要在 async 函数里只写
console.error却不 re-throw，否则调用方无法感知失败 - Promise.all 中某个失败默认导致整个数组 reject，如需“软失败”，应提前用 .catch() 捕获并返回默认值
- 避免在循环中无条件 await 多个请求——不仅性能差，还容易因前序失败阻断后续执行；改用 Promise.allSettled 更可控
- 全局监听 unhandledrejection，并记录 error.stack 和 url、时间戳等上下文，用于监控告警
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
