Sentry SDK 默认通过监听 window.onerror 和 unhandledrejection 自动捕获未处理的全局错误与 Promise 拒绝，无需手动 try/catch；漏报主因是 SDK 未初始化、DSN 错误、加载顺序不当或配置中误过滤。
Sentry SDK 默认就能自动收集并上报 JavaScript 异步错误，前提是正确初始化且环境配置到位。它不是靠你手动写 try/catch 或 .catch() 才触发的，而是通过监听浏览器原生事件实现的——关键就在这两个事件：window.onerror 和 window.addEventListener('unhandledrejection', ...)。
自动捕获的两类异步错误
Sentry 会主动监听并捕获以下两类未被处理的异常：
-
全局运行时错误：比如语法错误、
ReferenceError、TypeError等，触发window.onerror事件 -
未处理的 Promise 拒绝：当 async 函数中抛出错误、
fetch失败未catch、或Promise.reject()后无监听者时，触发unhandledrejection事件
为什么有些 Promise 错误“漏报”了
不是 Sentry 没能力，而是 SDK 没启用或没加载成功：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- SDK 未初始化（比如只在开发环境加载，生产环境被条件屏蔽）
- DSN 配置错误或为空，导致初始化失败但控制台无提示
- 脚本加载顺序问题：Sentry 初始化代码必须早于所有业务逻辑执行
- 使用了精简版 SDK（如仅引入
@sentry/browser但未开启 integrations），某些框架场景下需额外集成（如@sentry/vue或@sentry/react）
确保上报生效的关键配置
初始化时这几项不能省略或写错：
立即学习“Java免费学习笔记（深入）”；
- 必须传入有效 DSN：它是 Sentry 接收数据的唯一凭证，泄露风险高，建议用环境变量注入
-
显式声明
environment：如production或staging，否则错误会混在一起，难定位 -
绑定
release版本号：如"my-app@2.3.1"，配合上传 source map 才能还原压缩代码中的原始行号 -
不要过滤掉
unhandledrejection：检查是否在beforeSend中误判并return null，或设置了ignoreErrors正则误伤
验证是否真正在工作
上线前快速验证两件事：
- 在浏览器控制台执行：
throw new Error('test-error')→ 应在 Sentry 控制台看到新 issue - 再执行：
Promise.reject(new Error('test-promise'))→ 同样应出现在 Sentry，且类型标记为unhandledrejection - 如果第二个没出现，说明
unhandledrejection监听未生效，优先检查 SDK 加载和初始化时机
