异步错误不被try/catch捕获，是因为执行时机与作用域分离；需确认错误是否真被抛出、检查promise链是否漏catch、验证try/catch覆盖范围、用堆栈定位源头、全局监听unhandledrejection和error兜底。
异步错误不往上抛，本质是它根本没进入你的 try/catch 范围——不是代码写错了，而是执行时机和作用域断开了。关键要搞清“谁在什么时候、以什么身份抛出错误”，再针对性补位。
确认错误是否真的被抛出了
很多所谓“未抛出”，其实是被静默吞掉了。先打开浏览器控制台，留意是否有 Uncaught (in promise) 或 Uncaught TypeError 这类提示。如果有，说明 Promise 拒绝或异步异常确实发生了，只是没被处理。
- 检查 fetch、axios 等请求后有没有 .catch() 或 await 外层的 try/catch
- 检查 setTimeout/setInterval 回调里有没有 throw，这类错误不会触发外层 try/catch
- 在可疑异步函数开头加 console.log('start')，结尾加 console.log('end')，确认函数是否真的执行到了抛错那行
验证 try/catch 是否覆盖了正确的执行流
async 函数里只包 fetch() 不 await，等于白包；回调函数里 throw，永远逃不出外层 try/catch 的手掌心。
- 错误写法：
try { fetch('/api').then(...); } catch(e) { }→ then 内部报错不会进 catch - 正确写法：
try { const res = await fetch('/api'); ... } catch(e) { } - 回调场景下，别依赖 try/catch，改用 Promise 包装或监听 unhandledrejection
用堆栈和 trace 定位源头
异步错误堆栈常被截断，顶部是 Promise.then 或 async 函数封装层，真正出问题的代码往往藏在倒数第 2–4 行，带具体文件名和行号的那几行才是关键。
- 在可疑位置加
console.log(new Error().stack)，看调用链是否符合预期 - 用
console.trace()替代 log，直接输出完整调用路径 - Chrome DevTools 中右键点击报错信息 → “Reveal in Console” → 点击堆栈中的文件链接，快速跳转到源码行
兜底监听 + 上下文补全
即使业务层漏了处理，全局监听也能帮你捞回线索。重点不是“捕获到”，而是“知道在哪、谁、干了什么时出的问题”。
- 监听
unhandledrejection：捕获所有未 catch 的 Promise 拒绝，记得event.preventDefault()防止控制台干扰 - 监听
error：覆盖资源加载失败、定时器内抛错等场景 - 上报时带上当前路由、用户 ID（脱敏）、traceId、网络状态，让一次错误能关联前后操作
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
