async/await异常处理与全局捕获是分工明确的两层机制：前者用try/catch聚焦可控业务错误，后者用unhandledrejection等兜底未被捕获的意外崩溃；二者协同形成“主动防御+被动兜底”，不可互相替代。

async/await 的异常处理和全局异常捕获不是替代关系，而是分工明确的两层机制：前者聚焦于**可控的业务逻辑错误**，后者兜底**未被捕获的、意外的运行时崩溃**。

async/await 异常处理：专注业务流程中的可预期失败

它本质是 Promise 拒绝（rejection）的语法糖封装，核心在于用 try/catch 同步化地捕获 await 表达式抛出的错误。这种处理方式有明确的作用域和意图：

• 必须配合 await 使用：只有 await 一个 rejected Promise，才会触发 catch 块；单纯调用 async 函数不 await，错误不会进入 try/catch
• 能同时捕获同步与异步错误：比如在 await 后面紧接着执行 JSON.parse()，若解析失败，也会被同一 catch 捕获
• 支持细粒度控制：可在不同 await 步骤后分别处理错误，例如用户获取失败时跳转登录页，订单查询失败时提示重试，而不是统一弹“系统错误”

全局异常捕获：防御不可控的边缘崩溃

它不介入具体业务逻辑，而是监听那些逃逸出所有 try/catch 和 .catch() 的“漏网之鱼”，常见手段包括：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 浏览器中 window.addEventListener('unhandledrejection', ...)：捕获未被 .catch() 或 try/catch 处理的 Promise rejection
• 浏览器中 window.onerror：捕获同步脚本错误、资源加载失败等非 Promise 类型异常
• Node.js 中 process.on('unhandledRejection', ...) 和 process.on('uncaughtException', ...)：分别对应 Promise 拒绝和同步异常的终极兜底

二者协同的关键实践

真实项目中，两者应形成“主动防御 + 被动兜底”的组合：

• 不要依赖全局捕获代替业务 try/catch：全局监听无法知道错误发生的具体上下文（比如是哪个接口、哪次操作），难以做精准反馈或恢复
• 全局监听只做三件事：记录日志、上报监控、友好降级（如显示维护页），绝不在此处尝试“修复”或重试业务逻辑
• async/await 中的 catch 应尽量包含有意义的错误分类与用户提示，例如区分网络超时、权限不足、数据格式异常，并给出对应操作建议

典型误用场景提醒

容易混淆的点在于“以为写了 try/catch 就万无一失”：

• 忘记 await，导致 Promise rejection 未被触发为 throw，try/catch 形同虚设
• 在事件回调（如 button.onclick）里直接调用 async 函数却不 await，错误会直接飞到全局
• 把全局 unhandledrejection 当作开发调试工具，上线后不处理或仅 console.log，等于放弃可观测性

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南