try...catch仅捕获同步错误，适用于明确可能立即抛异常的场景，如JSON.parse、深层属性访问、同步API调用；需配合await捕获Promise拒绝，按error.name分类处理，finally仅用于无条件清理。
try...catch 只能捕获同步错误，对异步错误（如 setTimeout、未 await 的 Promise）、语法错误、资源加载失败等完全无效——这不是它设计来干的事。
什么时候该用 try...catch？
只在你明确知道某行代码「可能立刻抛出异常」，且你有能力或需要响应时才用。常见场景包括：
-
JSON.parse()解析用户输入或不可信响应时，字符串格式稍有偏差就会抛SyntaxError - 访问深层嵌套对象属性前，又不想写一长串
?.或&&判断（比如user.profile.address.city） - 调用浏览器同步 API 时可能失败：如
navigator.clipboard.readText()被拒绝、localStorage.setItem()触发QuotaExceededError - 第三方 SDK 文档明确写了「同步方法会 throw」，比如某些加密库的
decryptSync()
怎么写才不白写？避免三个典型误用
很多 try...catch 实际上没起作用，或者起了反效果：
-
别把整个函数塞进
try块里：错误定位困难，堆栈被掩盖，也掩盖了到底是哪一行出的问题 -
别漏掉
await还假装能捕获：fetch('/api').then(...)在try里，catch永远不会执行；必须写成await fetch(...) -
别空着
catch：不记录、不上报、不 fallback，等于静默吞掉错误，调试时只能靠猜
async function loadConfig() {
try {
// ✅ 正确：await + try/catch 捕获 Promise reject 和同步异常
const res = await fetch('/config.json');
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return await res.json(); // JSON.parse 异常也会被捕获
} catch (error) {
console.error('配置加载失败:', error.message);
return { theme: 'light', lang: 'zh' }; // fallback 默认值
}
}
如何区分错误类型，而不是全当一个错处理？
不是所有错误都该弹提示或重试。error.name 比 instanceof 更稳妥（跨 iframe 或模块时构造函数引用不同），推荐优先用：
-
SyntaxError：来自JSON.parse()、eval()等，通常是数据格式问题 -
TypeError：调用了非函数、读取null属性、传参类型不对 -
ReferenceError：访问了未声明的变量（开发阶段多见） -
NetworkError或自定义名：可由你主动throw new Error('NetworkError')标识
try {
const data = JSON.parse(userInput);
} catch (error) {
if (error.name === 'SyntaxError') {
alert('输入的 JSON 格式不对，请检查括号和引号');
} else if (error.name === 'TypeError') {
console.warn('解析后数据结构异常，使用默认配置');
} else {
console.error('未知解析错误:', error);
}
}
finally 不是“收尾万金油”，用错反而坏事
finally 总会执行，但它不是用来做业务判断的地方，而是无条件清理：
立即学习“Java免费学习笔记（深入）”；
- ✅ 适合：隐藏 loading、
clearTimeout()、AbortController.abort()、重置表单提交状态 - ❌ 避免：
finally中return会覆盖try或catch的返回值；在里面再发请求或调用可能出错的方法，容易掩盖原始错误 - ⚠️ 注意：
finally中如果throw新错误，原始错误就彻底丢失了
let timer;
try {
timer = setTimeout(() => { throw new Error('timeout'); }, 2000);
await doWork();
} catch (err) {
console.error(err);
} finally {
clearTimeout(timer); // ✅ 必须清理
setLoading(false); // ✅ UI 状态重置
// ❌ 不要在这里 return 或 throw
}
真正容易被忽略的点是：**try...catch 是一种有明确边界的防御手段，不是兜底开关**。它解决不了异步流失控、网络超时、服务端返回 500 却没 reject 的问题——那些得靠 AbortController、状态码校验、Promise.race() 或全局错误监听配合。用对地方，才能让错误变得可控、可追溯、不影响主流程。 
