17370845950

try-catch仅捕获同步错误，异步错误需结合async/await+try-catch、unhandledrejection监听等；finally用于资源清理；应抛Error实例而非字符串，便于调试与监控。

try-catch 捕获同步错误最常用，但别漏掉 finally

JavaScript 中 try-catch 是处理同步异常的标配，但它只捕获当前执行栈中抛出的错误，对异步操作（如 setTimeout、Promise 回调）无效。常见误用是以为加了 try-catch 就能兜住所有错误，结果发现 fetch 失败或 JSON.parse 报错仍导致白屏或未处理的 Uncaught SyntaxError。

实操建议：

• catch 块里务必检查 error 类型，避免把 null 或非 Error 实例当异常处理
• 需要清理资源（如关闭定时器、释放锁）时，把逻辑放在 finally 里，它无论是否出错都会执行
• 不要空 catch：至少记录 console.error(error) 或上报到监控系统

try {
  const data = JSON.parse(invalidJson);
  render(data);
} catch (err) {
  if (err instanceof SyntaxError) {
    console.error('JSON 解析失败:', err.message);
    showErrorMessage('数据格式异常');
  } else {
    throw err; // 不认识的错误，继续上抛
  }
} finally {
  hideLoading();
}

async/await 必须配合 try-catch，Promise.catch 不能跨 await 链自动传递

写 async 函数时，很多人习惯在最后链一个 .catch()，但这样会漏掉 await 后面语句抛出的错误——因为 await 已将 Promise 转为同步流程，错误不再走 Promise 链。

常见错误现象：await fetch('/api') 成功，但后续 await res.json() 报错，却没被外层 .catch() 捕获。

实操建议：

• 每个 await 行都应处于 try 块内，或确保前一个 await 的 Promise 已用 .catch() 处理并返回“安全值”
• 避免混合写法：不要在 async 函数里既用 try-catch 又在外层调用处再链 .catch()，容易重复处理或遗漏
• 注意 Promise.all：任一子 Promise 拒绝会导致整个失败，需提前用 .catch(() => null) 包装单个 Promise 来隔离错误

async function loadData() {
  try {
    const res = await fetch('/api');
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    const data = await res.json(); // 这行可能 SyntaxError，必须在 try 内
    return data;
  } catch (err) {
    console.error('加载失败:', err);
    return null;
  }
}

window.onerror 和 window.addEventListener('error') 用于捕获全局 JS 错误

这些机制能抓到未被 try-catch 捕获的运行时错误，包括脚本加载失败、语法错误、跨域脚本错误（但此时 error 对象信息受限，message 和 stack 为空）。

关键限制：它们不捕获 Promise 拒绝（unhandledrejection 是独立事件），也不捕获 console.error 手动打的日志。

实操建议：

• 必须在所有脚本执行前注册，否则早期错误会丢失
• 生产环境建议搭配 addEventListener('unhandledrejection', ...) 一起使用，覆盖 Promise 场景
• 注意跨域脚本：CDN 上的 JS 报错时，浏览器出于安全限制只给 Script error.，需在 标签加 crossorigin 属性并确保服务端返回 Access-Control-Allow-Origin

window.addEventListener('error', (event) => {
  console.log('全局错误:', {
    message: event.message,
    filename: event.filename,
    lineno: event.lineno,
    colno: event.colno,
  });
});

window.addEventListener('unhandledrejection', (event) => {
  console.log('未处理 Promise 拒绝:', event.reason);
});

throw new Error() 比 throw 'string' 更利于调试和分类

直接 throw '网络超时' 看似简单，但会让错误失去堆栈、类型和标准化属性，后续无法用 instanceof Error 判断，监控系统也难做聚合分析。

实际项目中，自定义错误类或带 code 的 Error 实例能显著提升问题定位效率，比如区分业务错误（AuthError）、网络错误（NetworkError）、校验错误（ValidationError）。

实操建议：

• 所有手动抛错统一用 new Error(msg)，哪怕只是临时调试
• 添加额外字段：如 err.code = 'NETWORK_TIMEOUT'、err.meta = { url, method }，便于日志筛选
• 避免在 catch 中吞掉原错误又不保留 err.stack，这会让排查断层

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

// 使用
if (!email.includes('@')) {
  throw new ValidationError('邮箱格式不正确', 'email');
}

错误处理真正难的不是语法，而是决定在哪一层抛、在哪一层收、哪些该静默、哪些必须阻断用户操作。尤其在微前端或 SDK 场景下，错误边界（componentDidCatch / errorBoundary）和跨沙箱错误透传，很容易被忽略。