async/await异常处理需显式await才能捕获错误，fetch需手动检查res.ok，堆栈需用throw new Error保全，应分层容错、区分错误类型并确保调用方处理Promise拒绝。
async/await 的异常处理不是“加个 try/catch 就完事”，关键在于让错误可定位、可区分、可恢复；堆栈追踪也不是默认就完整，不干预就会丢失原始抛出处。
错误必须显式 await 才能被捕获
await 是错误捕获的“开关”：只有被 await 的 Promise 拒绝，且该 await 位于 try 块内，错误才会进入 catch。漏写 await，得到的是未执行的 Promise 对象，不会触发 reject，也就无法捕获。
- ✅ 正确：
try { const data = await fetch('/api').then(r => r.json()); } - ❌ 错误：
try { const p = fetch('/api').then(r => r.json()); } // p 没 await，错误静默丢失 - ⚠️ 注意：fetch 网络失败（如断网）会直接 reject，但 404/500 等 HTTP 错误默认仍 resolve，需手动检查
res.ok并throw new Error()
堆栈信息天然被截断，需主动保全
JavaScript 中 async/await 不像 C# 那样自动丢失原始堆栈，但它对错误来源的“透明度”有限：浏览器控制台显示的 stack 通常止于 await 行，而非 throw 那一行——尤其当错误来自深层调用或第三方库时。
- 根本原因：V8 引擎将 await 后的恢复视为新执行帧，原始调用链被折叠
- 缓解方式：统一用
throw new Error('msg')，避免throw 'string'（后者无 stack） - 进阶技巧：在关键逻辑中手动增强上下文，例如：
const err = new Error('Failed to parse user config');<br>err.context = { stage: 'init', file: 'config.json' };<br>throw err;
按业务分层处理，避免一锅炖
一个 try 块包多个 await，看似简洁，实则掩盖问题、阻碍降级：前序失败会导致后续逻辑完全跳过，无法复用已成功获取的数据。
立即学习“Java免费学习笔记（深入）”；
- 推荐模式：为每个独立业务单元单独容错
const user = await getUser().catch(() => null);<br>const posts = user ? await getPosts(user.id).catch(() => []) : [];<br>const profile = await getProfile(user?.id).catch(() => ({})); - 区分错误类型再响应：
•err instanceof TypeError→ 提示“网络异常，请重试”
•err.message.includes('401')→ 清 token 并跳转登录
•err.code === 'ECONNABORTED'→ 显示加载超时提示 - catch 内必须做三件事：记录（
console.error或上报）、决策（重抛 / 返回默认值 / 降级）、不空着
兜底不能只靠函数内部
async 函数返回的是 Promise，即使内部有 try/catch，调用方若不处理这个 Promise 的拒绝状态，仍会触发 unhandledrejection，影响稳定性。
- 事件处理器中务必包裹：
button.addEventListener('click', async () => {<br> try { await loadData(); }<br> catch (e) { showError(e); }<br>}); - 全局监听作为最后一道防线：
window.addEventListener('unhandledrejection', e => {<br> console.warn('未捕获 Promise 拒绝:', e.reason);<br> // 上报监控系统<br>}); - 框架层（如 React）可用 Error Boundary 捕获渲染阶段异步错误，但不覆盖数据请求层的 try/catch
