try...catch仅捕获同步错误，无法捕获异步错误；异步错误需用Promise.catch()或async/await配合；catch必须声明错误参数；finally总会执行但慎用return；避免用其替代条件判断。
try...catch 不能捕获同步代码以外的错误
它只抓得到当前执行栈里抛出的 throw 错误或运行时异常，比如 ReferenceError、TypeError。异步操作（如 setTimeout、fetch、事件回调）里抛错，直接跳出 try 范围，不会进 catch。
常见错误现象：
– 写了 try { setTimeout(() => { throw new Error('boom') }, 0) }，但控制台报错且没进 catch
– fetch 请求失败时，catch 没触发，因为网络错误本身不抛异常，而是返回一个 Response 对象，需手动检查 response.ok
实操建议：
– 异步错误优先用 .catch()（Promise）或 await + try...catch（注意必须在 async 函数内）
– 事件监听器里的错误，只能在内部再包一层 try...catch
catch 块必须声明错误参数，否则语法报错
catch 后面的括号不是可选的——哪怕你不想用这个错误对象，也得写个形参，比如 catch (err) 或 catch (_)。漏掉会触发 SyntaxError: missing catch parameter。
立即学习“Java免费学习笔记（深入）”；
使用场景：
– 有些时候你只关心是否出错，不关心具体错误类型，仍需占位：catch (e) { console.log('fail'); }
– 不要用 catch {} 或 catch ()，浏览器和 Node.js 都不认
参数差异：
– 参数名无限制，但别叫 error（容易和全局 Error 构造函数混淆）
– 实际拿到的是 Error 实例，有 message、stack、name 等属性，不是原始字符串
finally 块不是“成功才执行”，而是“一定执行”
finally 在 try 或 catch 执行完后都会运行，不管有没有异常、有没有 return、甚至 catch 里又抛错，它都执行。
容易踩的坑：
– try { return 1; } finally { return 2; } → 整个函数返回 2，finally 里的 return 会覆盖前面的
– finally 里抛错，会直接取代 try/catch 中的错误，原错误丢失
– 不适合放纯业务逻辑，更适合做清理：关闭定时器、重置 loading 状态、释放资源
性能影响：
– finally 是同步执行的，不会延迟异步流程
– 如果里面含大量计算或 DOM 操作，可能阻塞主线程，慎用
不要用 try...catch 替代条件判断
比如检查对象属性是否存在，写成 try { x.y.z } catch { ... }，比直接 if (x?.y?.z) 或 in 检查慢一个数量级，V8 引擎对异常路径有额外开销。
使用场景对比：
– ✅ 适合：调用第三方库、JSON.parse、eval、DOM 方法（如 querySelector 可能因 selector 无效抛错）
– ❌ 不适合：判断变量是否为 null、数组长度、对象是否有 key、类型校验
可给出简短示例：try { JSON.parse(str); } catch (e) { console.error('invalid JSON'); } —— 合理try { obj.name.toUpperCase(); } catch { /* obj.name 可能是 undefined */ } —— 应该先 obj?.name
实际项目里最容易被忽略的是错误堆栈的完整性：catch 之后如果只是 console.log(err.message)，就丢掉了 err.stack，排查时找不到源头。真要处理错误，至少保留 err.stack 或用 console.error(err)。
