JavaScript异常捕获难点在于异步错误处理：try/catch仅捕获同步错误；Promise拒绝需用.catch()或async/await中try包裹await；全局未处理拒绝用unhandledrejection事件兜底；错误应自定义分类并结合业务语义决策重试、降级或中断。
JavaScript 中的异常捕获本身不难，难的是在真实项目里不漏掉异步错误、不吞掉有用堆栈、不误判 Promise 拒绝为“已处理”。try/catch 只对同步代码有效，而现代 JS 大量依赖 Promise、async/await 和事件回调，这些地方才是异常丢失的重灾区。
为什么 try/catch 抓不到 Promise 拒绝？
因为 Promise 的拒绝（reject）默认不是“抛出异常”，而是触发一个未处理的 rejection，浏览器或 Node.js 会等微任务队列清空后才报错——此时 try/catch 早已退出作用域。
常见错误写法：
try {
Promise.reject(new Error('boom'));
} catch (e) {
console.log('不会执行');
}
正确做法是显式处理 Promise 链：
立即学习“Java免费学习笔记（深入）”；
- 用
.catch()接住链尾拒绝 - 在
async/await函数中用try/catch包裹await表达式（注意：只对当前 await 有效） - 避免在
then()回调里抛错却不接catch()，否则变成 unhandledrejection
如何全局捕获未处理的 Promise 拒绝？
靠 window.addEventListener('unhandledrejection')（浏览器）或 process.on('unhandledRejection')（Node.js），但仅作兜底，不能替代主动处理。
关键点：
- 该事件只触发一次，且无法阻止默认行为（如控制台报错）
- 事件对象有
reason（错误对象）和promise（被拒绝的 Promise 实例） - 不要在这里
throw或reject，否则可能引发二次事件 - 适合做日志上报，不适合做业务恢复
示例（浏览器端）：
window.addEventListener('unhandledrejection', event => {
console.error('Unhandled rejection:', event.reason);
// 上报监控系统
reportError(event.reason);
// ⚠️ 不要写 event.preventDefault() —— 它无效
});
异步操作嵌套时，catch 该放在哪一层？
原则：谁启动异步，谁负责兜底；谁消费结果，谁决定错误走向。不要把所有 catch 堆在最外层。
典型陷阱：
- 在
fetch后直接.json()却没处理json()自身可能抛出的语法错误 - 多个
await连续调用，只在外层try，导致中间某步失败后后续逻辑仍执行 - 使用
Promise.all()时，一个失败就全盘 reject，但你其实只想忽略个别失败 —— 改用Promise.allSettled()
推荐结构：
async function loadData() {
try {
const res = await fetch('/api/data');
if (!res.ok) throw new Error(`HTTP ${res.status}`);
try {
const data = await res.json(); // 可能 SyntaxError
return data;
} catch (e) {
throw new Error('Invalid JSON response');
}
} catch (e) {
// 统一处理网络、解析、业务逻辑错误
logError(e);
throw e; // 保持可追溯性，不静默吞掉
}
}
错误对象本身该怎么构造和区分？
原生 Error 对象只有 message 和 stack，但真实场景需要类型、状态码、上下文数据。别只靠 instanceof 判断。
实操建议：
- 自定义错误类继承
Error，添加name、code、status等字段 - 避免用字符串匹配判断错误原因（如
e.message.includes('timeout')），改用e.code === 'NETWORK_TIMEOUT' - 在日志中保留原始
cause（ES2022+ 支持new Error(msg, { cause })） - 第三方库（如 Axios）的错误对象结构特殊，务必查文档，例如
error.response?.data才是后端返回体
示例：
class ApiError extends Error {
constructor(message, { code, status, details } = {}) {
super(message);
this.name = 'ApiError';
this.code = code;
this.status = status;
this.details = details;
}
}
真正难的不是写 catch，而是判断哪个错误该重试、哪个该降级、哪个该直接中断用户流程——这需要结合业务语义，而不是靠一套通用错误处理函数自动解决。
