JavaScript错误处理需提前预防、精准捕获、合理反馈、有效恢复；应选择性使用try-catch包裹高风险操作，结构化抛出错误，设置全局兜底，并借助严格模式与工具链提升健壮性。

JavaScript错误处理的核心是提前预防、精准捕获、合理反馈和有效恢复，而不是等到崩溃才去补救。

用try-catch有选择地包裹异步或高风险操作

不是所有代码都需要try-catch。它最适合用于明确可能抛出异常的场景，比如JSON.parse、DOM操作、第三方API调用或用户输入解析。

• 避免包裹整个函数或大片逻辑，否则会掩盖真实问题位置
• 异步代码中，await 后的Promise拒绝不会被同步try-catch捕获，需配合.catch()或在async函数内用try-catch
• 示例：解析用户粘贴的JSON时，必须加try-catch，否则非法字符串直接中断执行

统一错误分类与结构化抛出

不要只用throw "出错了"，应创建可识别、可追踪的错误对象。

• 继承原生Error类，添加code、status、timestamp等字段，便于监控系统归类
• 区分错误类型：NetworkError、ValidationError、AuthError等，让上层能针对性处理（如重试、跳登录、提示格式）
• 避免在catch里静默吞掉错误；至少记录到console.error或上报服务

全局兜底：window.onerror + window.onunhandledrejection

它们是最后防线，用来捕获未被局部处理的错误，不能替代主动错误处理。

• window.onerror捕获同步脚本错误、资源加载失败（如JS文件404）
• window.onunhandledrejection捕获未被catch的Promise拒绝，尤其要注意定时器、fetch未await等常见遗漏
• 两者都建议上报关键信息：错误消息、堆栈、URL、用户行为上下文（如当前页面、按钮ID）

开发期开启严格模式与工具链支持

很多错误其实在运行前就能发现。

• 启用"use strict"，让隐式全局、重复参数等潜在问题提前报错
• 用TypeScript或JSDoc做静态类型检查，减少undefined.property这类运行时错误
• 配置ESLint规则（如no-unsafe-finally、no-empty）和CI阶段自动检测未处理的Promise

不复杂但容易忽略：错误处理的目标不是让代码“不出错”，而是让错误变得可预期、可定位、可恢复。