javascript错误如何捕获_try catch语句怎么使用？

try catch 仅捕获同步运行时错误（如 ReferenceError、TypeError），无法捕获语法错误（解析阶段）、异步错误（需在回调或 async/await 中使用）、Promise reject（需 .catch() 或 await 配合 try catch）。

try catch 能捕获哪些 JavaScript 错误？

它只捕获**同步执行时抛出的运行时错误**，比如 ReferenceError、TypeError、SyntaxError（仅限 eval 中）、RangeError 等。异步代码（如 setTimeout、Promise 回调、事件处理器）里抛出的错误不会被外层 try catch 捕获。

• try catch 对语法错误（比如脚本顶层写错 if ( 缺少括号）完全无效——这类错误发生在解析阶段，脚本根本不会执行
• Promise 拒绝（reject）不是错误抛出，需用 .catch() 或 await 配合 try catch（且 await 必须在 async 函数内）
• 未捕获的 Promise rejection 会触发 unhandledrejection 事件，可全局监听，但不属于 try catch 范畴

基本写法与常见误用

结构固定：必须有 try 块，catch 和 finally 都是可选的；catch 参数（如 err）是错误对象，不是字符串。

try {
  JSON.parse('{ "name": "Alice"'); // 缺少 }
} catch (err) {
  console.log(err instanceof SyntaxError); // true
  console.log(err.message); // "Unexpected end of JSON input"
}

• 不要写成 catch (e.message)——参数是整个错误对象，e.message 是属性访问，不是解构
• 避免空 catch 块：catch (err) {} 会静默吞掉错误，极难调试
• finally 总会执行，哪怕 try 或 catch 中有 return；适合清理资源（如关闭定时器、重置状态）

如何捕获异步操作中的错误？

直接在 setTimeout 或事件回调里写 try catch 是唯一可靠方式；对 Promise，推荐 async/await + try catch，比链式 .catch() 更直观。

async function fetchData() {
  try {
    const res = await fetch('/api/data');
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return await res.json();
  } catch (err) {
    console.error('请求失败:', err.message);
    throw err; // 如需继续向上抛，别忘了 re-throw
  }
}

• fetch 本身不因 HTTP 状态码（如 404、500）抛错，必须手动检查 res.ok 或 res.status
• await 后的表达式若返回被拒绝的 Promise，会自动转为 throw，所以能被 catch 捕获
• 不要在 then 的第一个回调里写 try catch——它只包裹该函数内部，无法捕获 then 外部或上一个 then 抛出的错误

error.name 和 error.stack 有什么用？

error.name 标识错误类型（如 "TypeError"），比单纯看 message 更稳定；error.stack 是字符串，含调用栈信息，对定位问题位置至关重要，但不同环境（浏览器/Node.js）格式略有差异。

• 生产环境日志中，应同时记录 err.name、err.message 和 err.stack，三者缺一不可
• err.stack 可能暴露源码路径，上线前建议用 sourcemap 工具处理，或在服务端脱敏
• 自定义错误时，继承 Error 并设 name，能让 instanceof 判断和分类更准确：

  class ValidationError extends Error {
    constructor(message) {
      super(message);
      this.name = 'ValidationError';
    }
  }

实际项目里，最常被忽略的是错误边界的划分——不是所有地方都适合加 try catch，比如工具函数内部通常应让错误冒泡，由业务层统一处理；而用户输入解析、第三方 API 调用这些“外部边界”，才是重点防护区域。