如何捕获和处理Javascript中的错误_怎样编写健壮的Javascript错误处理逻辑？

try…catch仅捕获同步错误，对异步错误无效；需配合window.onError、window.onunhandledrejection兜底；promise链末尾须加.catch()；async/await中await必须被try包裹；应按错误类型分级处理。

用 try...catch 捕获同步错误，但别指望它能抓到所有异常

同步代码中的运行时错误（比如 undefined is not a function、Cannot read Property 'x' of NULL）可以用 try...catch 拦住。但它对异步操作（如 setTimeout、fetch、事件回调）里的错误完全无效——那些错误会直接抛到全局，触发 window.onerror 或 unhandledrejection。

常见误用是把整个页面逻辑包进一个 try...catch，结果发现点击按钮报错还是崩，因为事件监听器里的错误根本没被包裹。

• 只对明确可能出错的同步块使用，比如 jsON 解析、对象属性访问前的校验
• 避免嵌套过深：try 块里不要再塞大量分支逻辑，否则定位具体哪行出错变困难
• catch 中必须处理或重新抛出，不能只写个空 catch(e) {} —— 这等于静默吞掉错误

try {   const data = json.parse(rawInput);   return data.id.toUpperCase(); } catch (e) {   console.error('JSON parse or toUpperCase failed:', e.message);   return null; }

监听 window.onerror 和 window.onunhandledrejection 补全错误覆盖

浏览器中未被捕获的同步错误会触发 window.onerror，而 Promise 链中没加 .catch() 的拒绝会触发 window.onunhandledrejection。这两个是兜底关键。

注意：window.onerror 的参数顺序固定（message, source, lineno, colno, error），而 error 参数在某些浏览器（如旧版 safari）可能为 undefined，所以不能直接访问 error.stack。

立即学习“Java免费学习笔记（深入）”；

• window.onunhandledrejection 的 Event.reason 可能是 Error 实例，也可能是字符串或任意值，需做类型判断
• 两者都应在应用初始化最早期绑定，晚于某些脚本执行可能导致漏捕
• 不要只打印日志，至少要调用上报函数（如 reportError({ message, stack, url })）

window.onerror = function(message, source, lineno, colno, error) {   reportError({     message: error?.message || message,     stack: error?.stack || '',     url: window.location.href   }); };  window.onunhandledrejection = function(event) {   reportError({     message: event.reason?.message || String(event.reason),     stack: event.reason?.stack || '',     url: window.location.href   }); };

Promise 错误必须显式处理，链式调用中 .catch() 的位置很关键

Promise 构造函数内部抛出的错误会被自动转为拒绝状态，但如果不接 .catch()，就会变成 unhandled rejection。更隐蔽的问题是 .catch() 放错位置：比如写成 fetch().then().catch()，只能捕获 then 回调里的错误，而捕获不到 fetch() 自身网络失败（它其实已经拒绝了，但被 then 吃掉了）。

• 每个 Promise 链末尾都应有 .catch()，除非上层已确保统一拦截
• 推荐写法：fetch().catch(() => {}).then().catch() 或直接 fetch().then().catch()（因 fetch 失败本身就会 reject）
• 避免在 async/await 中忘记 try...catch：它和同步 try 一样，不包住 await 表达式就无效

async function loadData() {   try {     const res = await fetch('/api/data');     if (!res.ok) throw new Error(`HTTP ${res.status}`);     return await res.json();   } catch (e) {     console.error('API call failed:', e);     throw e; // 不要静默，让调用方知道失败   } }

错误分类和响应策略比“捕获”更重要

不是所有错误都需要相同处理。网络超时、用户输入非法、第三方 SDK 报错、内存溢出，应对方式天差地别。硬编码统一 alert 或刷新页面反而损害体验。

真正健壮的逻辑在于区分错误来源与严重程度：可恢复的（如重试）、需提示用户的（如表单校验）、应降级的（如关闭非核心功能）、必须上报并告警的（如核心 API 连续失败）。

• 用自定义错误类区分类型，比如 class NetworkError extends Error，便于后续条件判断
• 对 fetch 类请求，检查 error.name === 'AbortError' 可知是主动取消，不用上报
• 不要在生产环境用 alert() 或 console.error 替代用户可见反馈；静默失败比报错更糟糕

最常被忽略的一点：错误处理代码自己也可能出错。比如上报服务不可用时再抛错，会导致原始错误丢失。务必确保错误处理路径足够轻量且隔离。