try...catch仅捕获同步错误，无法处理语法错误、异步回调错误及未await的Promise拒绝；必须用于明确可能出错且需响应的场景，如JSON.parse、第三方SDK调用等。
JavaScript 中的 try...catch 是处理运行时错误最直接的方式，但它不是万能的——它捕获不了语法错误、异步回调中的未捕获错误（如 setTimeout 里的抛错），也不能拦截 Promise 拒绝（Promise.reject()）而不加 .catch() 或 await。
什么时候必须用 try...catch？
当你明确知道某段代码可能抛出错误，且你有能力或需要在错误发生时做响应（比如 fallback、日志、用户提示），而不是让整个脚本中断。典型场景包括：
-
JSON.parse()解析不可信字符串（服务端返回空、乱码、截断 JSON） - 调用第三方 SDK 方法，文档注明会 throw（如某些 Web API 的同步失败）
- 访问可能为
null或undefined的深层属性前，又不想写一长串&&判断 - 使用
localStorage.setItem()时，用户禁用存储或配额超限
try...catch 的基本结构和常见写法
语法固定：必须有 try 块，catch 块可选，finally 块也非必须但常用于清理。注意 catch 参数是错误对象，现代写法推荐显式声明参数名（如 err），避免隐式创建全局变量（旧版 IE 问题已基本不需考虑，但习惯要保持）。
try {
const data = JSON.parse(userInput);
render(data);
} catch (err) {
console.error('JSON 解析失败:', err.message);
showFallbackUI();
} finally {
hideLoading();
}
⚠️ 容易踩的坑：
- 只写
catch (e)却没检查e instanceof SyntaxError，结果把网络错误也当 JSON 错误处理了 - 在
catch里什么也不做（空catch），等于静默吞掉错误，调试时完全找不到源头 - 把大量无关逻辑塞进
try块，导致错误定位困难；应尽量缩小try范围，仅包裹真正可能出错的那 1–2 行
如何配合 Promise 和 async/await 使用？
try...catch 对 async/await 有效，因为 await 会把 rejected Promise 当作同步错误抛出；但它对未 await 的 Promise 无效。下面两种写法效果完全不同：
// ✅ 正确：await 后，reject 会被 catch 捕获
async function fetchUser() {
try {
const res = await fetch('/api/user');
return await res.json();
} catch (err) {
console.error('请求或解析失败', err);
}
}
// ❌ 错误：fetch() 返回 Promise 后就离开了 try 块，reject 不会被捕获
function badExample() {
try {
fetch('/api/user').then(r => r.json()).catch(handleError);
} catch (e) {
// 这里永远进不来
}
}
如果你必须用链式 .then().catch()，那就别套 try...catch，直接在末尾加 .catch()；混用容易误判错误流向。
为什么有时 try...catch 看似没生效？
最常见原因有两个：
-
错误发生在异步任务内部：比如
setTimeout(() => { throw new Error('boom') }, 100)，这个错误无法被外层try捕获，它属于事件循环下一次 tick 的独立执行上下文 -
错误被更上层的错误边界或全局处理器拦截：React 的
componentDidCatch、window.onerror或process.on('unhandledRejection')（Node.js）可能先于你的catch触发，尤其在框架中要注意错误冒泡顺序
真正难调试的，往往是那些跨异步边界、又没被任何 catch 或 .catch() 接住的错误——它们最终变成 unhandled rejection 或 uncaught exception，只能靠全局监听兜底。这时候光靠 try...catch 是不够的。
