try-catch仅捕获同步异常，如JSON.parse失败、undefined属性访问等；异步错误需在回调内使用或配合await；finally总会执行但不吞错；全局监听仅用于上报而非恢复。
JavaScript 错误处理不是只有 try-catch 一种方式，但它是同步代码中捕获和响应异常最直接、最可控的手段。异步场景下它默认不生效，必须配合其他机制补全。
什么时候 try-catch 能捕获到错误
try-catch 只能捕获同步执行过程中抛出的异常（throw 或运行时错误），比如 JSON.parse 解析失败、访问 undefined 的属性、调用不存在的方法等。
常见误区是以为它能捕获 setTimeout、Promise、事件回调里的错误——其实不能，除非你在回调内部自己写 try-catch。
- ✅ 能捕获：
JSON.parse("{")、undefined.foo()、throw new Error("boom") - ❌ 不能直接捕获：
Promise.reject()、fetch().catch()、setTimeout(() => { throw "oops" }) - ⚠️ 注意：
async函数里await后的 Promise rejection 会被转为同步异常，此时try-catch有效
try-catch-finally 各部分的实际作用
finally 块无论是否发生异常都会执行，适合做清理工作（如关闭加载状态、释放资源），但它不会“吞掉”错误——如果 catch 中没 return 或 rethrow，错误仍会向上冒泡。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
示例：
try {
riskyOperation();
} catch (err) {
console.error("处理失败", err.message);
// 没有 rethrow，错误到这里就结束了
} finally {
setLoading(false); // 总会执行
}
-
catch参数名不是固定err，可以是任意合法标识符，如e、error -
catch块内若再次throw，错误继续向外传播；若只console.error不处理，等于静默丢弃 -
finally中return会覆盖try或catch中的返回值（慎用）
Promise 和 async/await 中的错误捕获要点
Promise 链中错误需用 .catch() 或 await 配合 try-catch，两者语义不同：前者是异步错误处理管道，后者是语法糖包装后的同步风格异常流。
- ❌ 错误写法：
try { Promise.reject("fail") } catch(e) { ... }—— 这里Promise.reject不抛同步异常 - ✅ 正确写法1：
Promise.reject("fail").catch(console.error) - ✅ 正确写法2：
async () => { try { await Promise.reject("fail") } catch(e) { ... } } - ⚠️ 注意：
await后面如果不是 Promise，try-catch仍按同步逻辑工作（比如await JSON.parse("{")会进catch）
全局错误监听作为兜底方案
未被任何 try-catch 或 .catch() 捕获的错误，会触发全局事件。浏览器中可用 window.onerror 或 window.addEventListener("error")；Node.js 中用 process.on("uncaughtException")。
但它们只是监控和上报手段，不适合用来“恢复”程序状态——因为错误发生时执行栈已不可控，强行续跑容易引发更隐蔽的问题。
-
window.onerror能捕获脚本错误、资源加载失败（如 JS 文件 404），但捕获不到 Promise rejection（需额外监听unhandledrejection） -
unhandledrejection事件可用于拦截未被.catch()处理的 Promise 错误，常用于日志记录 - 这些监听器不能替代局部错误处理，只是最后一道防线
真正难的不是写 try-catch，而是判断该不该捕、在哪捕、捕了之后怎么响应——比如解析用户输入的 JSON，失败要提示；但某个非关键埋点上报失败，通常该静默忽略。边界模糊的地方，往往得结合业务语义来定。
