17370845950

JavaScript错误处理核心是try-catch，但需明确目的、精准范围、保留上下文、及时上报，并协同finally与全局监听；只捕获可处理的错误，避免静默失败。

JavaScript 错误处理的核心是 try-catch，但它不是万能的“兜底开关”。用得不当，反而会掩盖问题、干扰调试，甚至导致静默失败。关键在于：明确捕获目的、精准控制范围、保留上下文、及时上报，并配合其他机制协同防御。

只捕获你有能力处理的错误

不要为了“看起来健壮”而层层包裹 try-catch。捕获后却只是 console.log 或空 catch，等于主动放弃诊断线索。

• 适合捕获：网络请求失败（可降级展示）、JSON 解析异常（用户输入非法）、DOM 操作目标临时缺失（可重试或忽略）
• 不适合捕获：未定义变量引用、null 调用方法、逻辑断言失败——这类应靠开发阶段的 ESLint、TypeScript 和单元测试提前暴露
• 如果 catch 后无法恢复业务流程，就该重新抛出：throw error; 或包装后抛出：throw new Error(`API failed: ${error.message}`);

始终访问 error 对象的完整信息

别只依赖 error.message。现代浏览器中 error.stack、error.name、error.fileName、error.lineNumber 都是关键线索，尤其在压缩代码中定位原始位置。

• 日志上报时至少包含：name、message、stack、触发时的 URL、用户操作路径（如按钮 ID）、时间戳
• 对 SyntaxError、TypeError、ReferenceError 等做类型判断，便于分类告警：if (error instanceof TypeError) { ... }
• 避免 catch (e) { console.error(e); } —— 这会丢失堆栈格式，建议用 console.error('API fetch failed:', error);

避免在 try 块中塞入过多无关逻辑

try 块越小，越容易定位错误源头。把数据转换、状态更新、副作用调用等拆到 try 外，只包裹真正可能抛错的那部分（比如 fetch() 或 JSON.parse()）。

• ❌ 不推荐：
  try {
    const res = await fetch('/api');
    const data = await res.json();
    setLoading(false);
    updateUI(data);
  }
• ✅ 推荐：
  try {
    const res = await fetch('/api');
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    const data = await res.json(); // 只这一行可能 JSON 解析失败
  } catch (error) {
    handleApiError(error); // 统一处理，不混业务逻辑
  }setLoading(false); // 放在外面，确保执行

结合 finally 和全局错误监听形成立体防御

finally 是清理资源（如关闭加载态、释放锁）的可靠位置；而 window.onerror 和 window.addEventListener('unhandledrejection') 能捕获 try-catch 漏掉的错误（如顶层异步拒绝、脚本加载失败）。

• 为 Promise 链补上兜底：Promise.reject(err).catch(handleError) 或全局监听 unhandledrejection
• 在 finally 中重置 UI 状态、取消 pending 请求（如有 AbortController），但不要在里面抛新错误
• 全局监听仅用于日志和监控，**绝不**在此做 UI 提示或流程干预——它已脱离原始上下文，无法准确响应

基本上就这些。try-catch 不是错误的终点，而是诊断的起点。写的时候多问一句：“我捕获后真能改善用户体验，还是仅仅让控制台安静了？”