async/await需配合try-catch或.catch()捕获错误，关键在合理使用：每个关键await应置于独立try-catch中，避免漏写await、混用同步错误，并按业务单元拆分处理，细粒度判断错误类型，调用方必须处理返回的promise。
async/await 本身不自动捕获错误，必须配合 try-catch 或 .catch() 才能防止 Promise 拒绝导致的未处理异常。关键不在“用不用”，而在“怎么用才合理”——既要避免错误被静默吞掉，也要防止错误处理逻辑污染主流程。
await 必须在 try 块内才能被捕获
只有被 await 的 Promise 进入 rejected 状态，且该 await 语句位于 try 块中，错误才会进入对应的 catch。漏写 await（比如写成 fetch('/api') 而不是 await fetch('/api')）得到的是一个未执行的 Promise，不会触发 reject，也就不会进 catch。
- ✅ 正确：把每个关键 await 放进独立的 try-catch，或确保它处于 try 块作用域内
- ❌ 错误：在 try 外 await，或把 await 写成普通表达式（无 await）
- ⚠️ 注意：try 块里混入同步错误（如 undefined.xxx）也会被同一 catch 捕获，需留意错误来源
按业务单元拆分错误处理，而非堆砌一个大 try
多个无关异步操作共用一个 try-catch，会导致前一个失败后后续逻辑完全跳过，丢失上下文、无法复用已成功获取的数据，也难以定位具体哪一步出错。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 推荐为每个独立请求单独兜底，例如：
const user = await getUser().catch(() => DEFAULT_USER) - 对强依赖链（如“先取用户 → 再取其订单”），可保留串行 try-catch，但应在 catch 中明确区分错误来源（如加日志标识）
- 并发请求（如同时拉用户和配置）应先触发所有 Promise，再统一 await，避免人为串行化
错误类型要细粒度判断，不能一 catch 了之
网络中断、401、404、500、解析失败、业务校验不通过……不同错误对应不同响应策略。直接 console.error(err) 不足以支撑稳定体验。
- 检查
err.name（如 'TypeError' 表示网络层失败）、err.status（HTTP 状态码）、err.message关键字做分支处理 - 401 → 清 token 并跳登录页；404 → 显示空状态页；网络错误 → 提示“请检查网络”并提供重试按钮
- 未预期错误（如 ReferenceError）应上报监控，并 fallback 到安全默认值，避免白屏或卡死
调用方必须处理 async 函数返回的 Promise
async 函数本质返回 Promise，内部 try-catch 只是局部兜底。如果调用方（如事件回调、组件生命周期）没接住这个 Promise 的拒绝，就会触发 unhandledrejection，影响稳定性甚至被监控系统告警。
- 在顶层入口（如 React useEffect、Vue onMounted）中，建议用
.catch()或全局监听window.addEventListener('unhandledrejection')做最后一道防线 - 封装工具函数时，明确文档是否“已内部兜底”，避免调用方误以为无需处理
- 不建议在 catch 中 silent 吞掉错误（如空 catch 块），至少要 log 或上报
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
