防止异步异常静默丢失的关键是明确捕获责任方、补全上下文与上报通路：在顶层await处用try-catch兜底，补全.catch()或监听unhandledrejection，禁用空catch，增强traceid与业务标记并保障上报。
防止异步异常在边界处被静默吞掉，核心是打破“错误不冒泡、不被捕获、不上报”的断层。关键不在加更多 try-catch，而在于明确每类异步场景的捕获责任方，并补全上下文与上报通路。
用 try-catch + await 正确包裹顶层异步调用
async 函数内部的 await 不会自动把 Promise rejection 转为同步异常；必须显式用 try-catch 包裹，否则错误会直接变成未捕获 rejection：
- ✅ 正确：启动异步操作的地方就该负责兜底，比如组件初始化、按钮点击事件中调用 fetchUser() 时加 try-catch
- ❌ 错误：只在内部函数里 catch（如 fetchUser 内部 try-catch 后又 throw），但调用方不处理——错误仍在边界处丢失
- 建议对每个顶层 await 操作单独判断：是否允许失败？失败后是重试、降级、提示，还是必须中断流程？按需决定是否 catch 或继续向上抛
补全 Promise 链末尾的 .catch() 或全局 unhandledrejection 监听
Promise 构造或链式调用中，一旦漏掉 .catch()，错误就会静默消失。尤其注意以下三类易漏点：
- fetch 后直接 .then(res => res.json())，没接 .catch() —— JSON 解析失败即静默
- setTimeout 中手动 throw new Error()，不属于 Promise，但也不会触发 try-catch，需靠 window.addEventListener('error') 捕获
- 务必监听 unhandledrejection：它专抓未被 .catch() 或 await 处理的 rejected Promise；调用 event.preventDefault() 可屏蔽控制台警告，但不影响你自行上报
避免“空 catch”和错误类型误判
catch 块不是保险箱，写得不当反而制造黑洞：
- 禁止空 catch {}：至少 console.error(err) 或调用统一上报函数，否则等于主动吞错
- 不要只依赖 err.message 判断错误类型；优先用 instanceof（如 err instanceof TypeError）或 err.name 字段，因为 Promise rejection 的 reason 可能是字符串或非 Error 实例
- 若需包装后重新抛出，用 throw new Error(`业务上下文: ${err.message}`)，保留原始 stack（可通过 err.stack 追溯）
增强可追溯性：给异步操作打上 traceId 和业务标记
静默错误难定位，往往不是没捕获，而是捕获后缺乏上下文：
- 在发起请求前生成或继承 traceId（例如从路由参数、localStorage 或全局 context 获取），并透传到错误上报 payload 中
- 记录当前页面路径、用户 ID（脱敏）、设备信息、网络状态（navigator.onLine）、SDK 版本等字段，让一次错误能关联到具体用户行为
- 对高频错误做节流（如 1 分钟内同类错误仅上报 1 次），但首次必须上报；本地 localStorage 缓存未发出的日志，下次打开页面补传
不复杂但容易忽略：异步错误不会自己说话，你得给它配麦克风、身份证和快递员——捕获是起点，上下文是耳朵，上报是腿。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
