async/await 不自动捕获异常，必须用 try/catch 包裹 await 表达式；未捕获的 promise rejection 会触发全局错误；顶层 await、useeffect 中 await 必须加 try；catch 可按错误类型分流处理；finally 适合清理但不可 await。
async/await 本身不捕获异常，必须配合 try/catch 才能真正“优雅”地处理错误——不是加了 await 就自动兜底，而是要主动用 try 包住可能出错的异步操作。
try/catch 必须包裹 await 表达式
await 后面的 Promise 如果被 reject，会直接抛出错误，就像同步代码中 throw 一样。如果不被 try 捕获，就会变成未处理的 Promise rejection，触发全局错误（如 unhandledrejection 事件），甚至导致进程退出（Node.js）或中断 UI（浏览器）。
- ✅ 正确：把 await 写在 try 块里，错误能被捕获
- ❌ 错误：只对 async 函数加 try，但 await 写在 try 外；或漏掉某个 await
不要在顶层作用域直接 await（无 try 包裹）
模块顶层、IIFE 外部、或事件回调里直接写 await，等于裸奔——没地方 catch。常见翻车场景：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 在 .js 文件最外层写
await fetch('/api')→ 报错就崩 - React 中 useEffect 里写了 await 却没 try → 错误静默丢失或触发白屏
- 解决方案：用立即执行函数包裹，或封装成带错误处理的工具函数
catch 中可区分错误类型，做精准响应
不是所有错误都该同等待遇。比如网络超时、401 未登录、500 服务异常，处理逻辑完全不同。
- 用
instanceof判断原生错误（如 TypeError、AbortError） - 检查 response.status 或自定义 error.code 字段做业务分流
- 示例：
if (err.name === 'AbortError') { /* 请求被取消 */ }
finally 适合收尾清理，但别放异步操作
finally 保证执行，适合关 loading、释放资源、重置状态。但它不接收错误参数，也不该 return 或 await ——否则会干扰原始错误传播。
- ✅ 可以：
loading.value = false、controller.abort() - ❌ 避免：
await api.logError(err)（会吞掉原始错误，且可能失败） - 若真需上报，用
void logError(err)或确保它不 throw
不复杂但容易忽略：async/await 的错误流本质是同步式的，写法像同步，行为也像同步——该 try 的地方就得 try，少一层就漏一层。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
