try-catch仅捕获同步错误，异步错误需用Promise.catch()、await+try-catch、unhandledrejection监听；全局监控需过滤跨域噪音并结合框架错误边界。
try-catch 只能捕获同步错误，异步代码里直接写没用
很多人以为把 setTimeout 或 fetch 包进 try 块就能抓到错误，其实不行。因为回调函数或 Promise 的执行时机在当前调用栈之外，try-catch 的作用域已经退出了。
-
try { setTimeout(() => { throw new Error('boom') }, 0) } catch(e) { }—— 这个catch完全不会触发 - 想捕获 Promise 错误，必须用
.catch()或await配合try-catch（且该try必须包裹await表达式本身） - 事件监听器里的错误（比如
button.addEventListener('click', () => { badFn() })）也逃逸出try范围，需单独处理
window.onerror 和 window.addEventListener('error') 的区别
window.onerror 是老接口，只能拿到错误消息、脚本 URL、行号、列号和错误对象（部分浏览器支持），但对 Promise 拒绝默认不响应；而 window.addEventListener('error') 是更通用的捕获机制，但它主要捕获资源加载失败（如 
- 真正要覆盖未捕获的 JS 异常，得同时监听：
window.addEventListener('error', handler)（针对资源）和window.addEventListener('unhandledrejection', handler)（针对 Promise） -
window.onerror返回true可阻止错误冒泡到控制台，但现代实践中更推荐用addEventListener方式，语义更清晰 - 注意：
unhandledrejection事件的event.reason才是实际错误对象，不是event.error
全局错误监控必须过滤掉常见噪音
上线后发现 80% 的错误日志是“Script error.” 或来自 CDN、广告脚本、浏览器插件——这些无法获取堆栈，也没法修复，反而淹没真实问题。
- 检查
event.filename或error.stack是否包含你自己的域名或构建产物路径（如/static/js/main.[a-z0-9]+.js） - 对
unhandledrejection，先判断event.reason instanceof Error，避免把字符串拒绝（如Promise.reject('oops')）当成结构化错误上报 - 加个简单采样逻辑，比如只上报前 10% 的同类型错误，防止日志风暴：
if (Math.random() > 0.1) return;
Vue/React 应用里别只靠全局监听
框架有自己的错误边界机制，比纯全局监听更精准。比如 Vue 的 errorCaptured 钩子或 app.config.errorHandler，React 的 componentDidCatch 或 createRoot 的 onRecoverableError，它们能定位到组件层级，还能保留上下文状态。
立即学习“Java免费学习笔记（深入）”；
- 全局
error监听不到组件内部setup()中的同步错误（Vue 3），必须靠app.config.errorHandler - React 18 后，服务端渲染时的 hydration 错误不会触发
window.onerror，得依赖onRecoverableError - 不要在
errorCaptured或componentDidCatch里再抛错，否则会再次触发全局监听，形成循环
crossorigin="anonymous"，它的错误就只会报 “Script error.”，连行号都没有。这个限制由浏览器强制执行，任何 JS 逻辑都绕不过。 
