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
不复杂但容易忽略：错误处理的目标不是让代码“不出错”，而是让错误变得可预期、可定位、可恢复。
发现。