async 函数可通过结构化设计构建错误捕获边界：用 try/catch 封装关联 await 操作，校验响应有效性，按 error.name、自定义 Error 类型分层处理；辅以 .catch() 和 unhandledrejection 监听兜底；封装安全请求函数复用错误逻辑。

async 函数本身没有内置的“错误边界”概念（那是 React 的术语），但可以通过组合 JavaScript 原生机制，构建出类似效果的**错误捕获边界**——即在特定作用域内拦截、分类、响应异步错误，防止其无序冒泡或静默丢失。核心不在于“配置”，而在于结构化设计。

用 try/catch 封装关键异步流程

这是最直接有效的错误边界。把一组有业务关联的 await 操作包裹在同一个 try 块中，一旦任一环节 reject 或 throw，立即进入 catch 处理，避免后续代码执行错乱。

• 每个 await 后都应检查响应有效性（如 res.ok、data.code === 0），不能只依赖网络层是否成功
• catch 中不要仅打印 error，要根据错误性质做差异化响应：401 跳登录、503 提示重试、TypeError 显示网络异常
• 若需继续执行（比如失败后返回默认值），可在 catch 中 return 合理兜底数据，而非一律 throw

按错误类型分层判断与处理

单纯 catch 所有 error 不够精准。真正健壮的边界需要识别错误来源和语义：

• 用 error.name 区分原生错误（TypeError、SyntaxError、AbortError）
• 对 HTTP 错误，手动 throw 并设置 name: 'HttpError' 和 status 字段，便于统一识别
• 高频业务错误（如登录过期、权限不足）建议定义继承 Error 的类（如 AuthExpiredError），用 instanceof 判断，比字符串匹配更可靠

外层加 Promise.catch 或全局 unhandledrejection 监听

try/catch 是第一道防线，但无法覆盖所有场景（比如忘记 await、Promise 构造函数里抛错）。需补充兜底机制：

• 调用 async 函数时，显式链式调用 .catch()，尤其适用于事件处理器或顶层入口
• 浏览器中尽早注册 window.addEventListener('unhandledrejection')，捕获漏网的 Promise rejection，用于日志上报或用户提示
• 注意：unhandledrejection 不会触发 fetch 成功但状态码为 404 的情况——因为 fetch 返回的是 resolve 的 Response 对象，必须手动检查并 throw

封装可复用的安全请求函数

把重复的错误判断逻辑抽离成工具函数，让业务代码专注处理成功路径：

• 接收一个 promise 创建函数（而非已执行的 Promise），避免调用时就失去拦截时机
• 在内部统一校验 HTTP 状态、JSON 解析、业务 code，并将不同错误类型标准化抛出
• 支持传入 onError 回调，实现错误响应策略的外部注入（如弹窗、跳转、重试）