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替代用户可见反馈；静默失败比报错更糟糕
最常被忽略的一点：错误处理代码自己也可能出错。比如上报服务不可用时再抛错，会导致原始错误丢失。务必确保错误处理路径足够轻量且隔离。
