17370845950

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 是不够的。