JavaScript错误处理核心是try-catch，但需明确目的、精准范围、保留上下文、及时上报，并协同finally与全局监听；只捕获可处理的错误，避免静默失败。
ry-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 不是错误的终点，而是诊断的起点。写的时候多问一句：“我捕获后真能改善用户体验，还是仅仅让控制台安静了？”
