async/await异常处理需精准捕获await抛出的promise拒绝值，避免漏catch导致白屏；并行请求依场景选promise.all或allsettled；全局监听unhandledrejection并封装api错误响应，保障流程不中断。
async/await 的异常处理直接决定前端应用是否“扛得住”。写错一行 await 或漏一个 catch，就可能让页面白屏、状态错乱、用户数据丢失——这不是危言耸听，而是每天都在发生的线上事故。
try/catch 是最常用也最容易用错的方式
它看起来像同步代码的错误处理，但实际作用对象是被 await 的 Promise 拒绝值。关键点在于：只有 await 表达式抛出的错误才能被同一 try 块捕获；如果 await 后面跟的是普通值、未被 await 的 Promise，或者错误发生在 .then 链里，catch 就失效。
- 只包裹真正可能失败的异步操作，避免把整个函数逻辑塞进 try 块
- 每个 await 前后不加 await 就等于放弃控制权，错误不会触发 catch
- catch 中不要静默吞掉错误，至少记录日志或返回默认值（如 null、[]），防止后续逻辑因 undefined 崩溃
并行请求要区分“全量失败”和“部分失败”
用 Promise.all 发起多个请求时，默认是“快速失败”：只要一个 rejected，整个 Promise.all 就 reject，其余还在进行的请求不会自动取消，但结果全丢。这在列表页加载头像、评论、标签等场景下极不友好。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 需要全部成功才继续 → 用 Promise.all + 外层 try/catch
- 允许部分失败、降级渲染 → 改用 Promise.allSettled，再过滤 fulfilled 结果
- 单个请求独立容错 → 给每个 fetch 加 .catch() 返回兜底值，再 await 解构
错误不能只靠局部捕获，得有兜底防线
开发时很难穷尽所有异常路径，比如第三方 SDK 抛错、事件监听器里的 await 失败、顶层组件生命周期中未 await 的 Promise。这时候全局监听就是最后一道保险。
- 监听 unhandledrejection 事件，上报错误并提示用户“功能暂不可用”
- 配合自定义错误类（如 NetworkError、ValidationError），便于分类统计和监控告警
- 在入口 async 函数外层统一包装一层错误处理器，避免每个页面重复写 try/catch
别让错误传播中断正常流程
async 函数内部 throw 错误，会使其返回的 Promise 变成 rejected 状态。如果调用方没处理，错误就向上冒泡，最终可能卡住状态更新、阻断 UI 渲染，甚至让 React 组件陷入崩溃状态。
- API 层返回的 Promise 建议统一封装，失败时不 throw，而是 resolve({ error, data })
- 业务层根据 error 字段判断是否需要重试、跳转、弹窗，而不是依赖 try/catch 控制流
- 对非关键路径（如埋点上报、静态资源预加载）使用 .catch(() => {}) 静默处理，避免影响主流程
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
