async函数未处理异常不会直接崩溃页面，但会导致错误静默丢失、业务逻辑中断、用户感知破坏及调试监控困难；其本质是promise拒绝未捕获，引发unhandledrejection事件或进程终止，后续代码跳过执行，调用方无反馈，框架不兜底，多异步操作丧失容错能力，且错误难定位监控。
async 函数内部未处理的异常，不会直接让页面崩溃，但会引发一系列隐蔽而严重的问题：它会让错误静默丢失、中断业务逻辑、破坏用户感知，并给调试和监控带来巨大障碍。
导致 Promise 拒绝未捕获
async 函数返回的是 Promise。一旦内部抛出异常且未被 try/catch 捕获，这个 Promise 就会进入 rejected 状态，且无人响应——即“未处理的 rejection”。浏览器会触发 unhandledrejection 事件，Node.js（v15+）则默认终止进程（除非显式监听）。这类错误在控制台仅显示一行警告，不打断执行，却可能掩盖真正的问题根源。
后续代码全部跳过，逻辑链断裂
await 后的异常一旦发生，函数立即退出，后面所有语句都不会执行：
-
console.log、状态赋值、副作用操作全被跳过 —— 比如
await api.login()失败后，this.loading = false和this.user = data都不会运行 -
调用方收不到任何反馈 —— 若父函数只是
init()而非init().catch(...)，错误就悬在空中 -
框架不自动兜底 —— Vue 的
mounted或 React 的useEffect中抛出未捕获异常，不会触发 error boundary，也不会阻止组件渲染
多个异步操作“连坐失效”，丧失容错能力
顺序 await 下，前一个失败，后续请求根本不会发起：
-
const user = await fetchUser()→ 失败 →const list = await fetchList()不执行 - 本可并行的请求被迫串行，且无法降级（比如 fallback 到缓存或空数据）
- 想实现“部分成功”，必须改用
Promise.allSettled或对每个 await 单独包 try/catch
错误难以定位与监控
未处理的异常缺乏上下文，排查成本高：
-
堆栈信息残缺 ——
unhandledrejection中的reason.stack往往只包含 Promise 创建点，而非原始 throw 位置 - 日志和上报缺失 —— 若没配全局监听，错误只留在控制台，线上环境几乎不可见
-
空 catch 更危险 ——
catch(e) {}主动吞掉错误，既不打印也不上报，等于关闭所有告警通道
不复杂但容易忽略，关键在于把异常处理当成异步流程的必经环节，而不是补救手段。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
