1. 错误处理的基础
1.1 异常与错误的区别
在 JavaScript 中，异常和 错误常被交替使用，但它们在语义上有细微差别。错误通常指语法或运行时的不可预期事件，而 异常则是运行时抛出的信号，用来中断当前流程并转入处理路径。理解这两者的关系有助于我们正确使用 try-catch 来提高健壮性和可维护性。
在实践中，使用 try 块包裹可能抛出异常的代码，配合 catch 块进行集中处理，是实现模块化错误处理的核心思路。通过对异常进行分类，我们可以决定是简单重试、回退策略、还是记录日志并向用户展示友好信息。此处的关键是将非预期的错误与可控的业务逻辑分开处理。
1.2 常见错误类型与场景
常见的错误类型包括 语法错误、运行时错误、网络请求失败、以及 数据解析错误 等。它们的出现场景各不相同，但处理思路大同小异：先识别错误来源，再决定是否继续执行、给出提示或进行回退。把握这个脉搏，可以让后续的错误处理更加清晰和高效。
一个良好的实践是在可能失败的位置明确抛出自定义错误，方便上层统一处理。通过这种方式，错误的上下文信息被保留，诊断成本显著降低。下面的示例展示了如何使用 try-catch 捕获并处理运行时错误。
try {// 可能抛出错误的代码const value = JSON.parse('{"name": "Alice"');
} catch (err) {console.error('解析 JSON 时出错：', err);
}
2. 使用 try-catch 捕获异常的基本用法
2.1 基本语法
try 块中放置可能抛出异常的代码，catch 块用于捕获错误并进行处理。通过 catch 的参数，可以访问异常对象，进而做出针对性的响应。该模式是同步代码中最常见也是最直接的错误处理方式。
需要注意的是，当不确定某段代码是否会抛出异常时，可以把它放在 try 块内，以避免未处理的异常导致应用崩溃。与此同时，合理组织错误处理逻辑，避免在 catch 中吞掉错误信息，是提升可维护性的关键。
try {// 可能抛出错误的操作const data = JSON.parse('{"foo": 1}');
} catch (err) {// 捕获异常后进行处理console.error('JSON 解析失败:', err);
}
2.2 捕获不同类型的异常与日志记录
不同的异常类型可以引导不同的处理路径。一般来说，可以根据错误名称、错误消息或自定义错误类型进行分流。日志记录是提高后续诊断效率的关键步骤，应该在 catch 块中对错误信息进行完整记录。
通过将错误信息写入本地日志、远端日志聚合系统或用户提示信息中，可以实现更好的运维与用户体验。下面给出一个带有简单日志策略的示例。
try {// 可能抛出错误的操作const res = await fetch('/api/data');if (!res.ok) throw new Error('网络响应不OK');const data = await res.json();
} catch (err) {// 分类处理和日志记录if (err.message.includes('网络')) {console.error('网络错误，请稍后重试:', err);} else {console.error('数据处理错误:', err);}
}
3. 高效的错误处理策略
3.1 全局错误处理与层级设计
在大型应用中，合理的错误处理策略不仅仅在单一位置进行捕获，还应该在层级间传递与转译错误。通过将错误从低层模块“翻译”为高层可理解的业务错误，可以实现统一的错误出口，降低耦合度。全局处理入口通常负责对未捕获的异常进行兜底处理、记录日志和触发回退流程。
同时，层级设计有助于区分“可以恢复的错误”和“不可恢复的错误”。前者在局部范围内进行重试或降级，后者则快速回退并向用户提供友好提示。
3.2 日志、监控与告警
高效的错误处理离不开完善的日志与监控。结构化日志、请求上下文、以及错误堆栈信息的完整记录，是后续排查的基石。结合监控系统，可以实现对错误率、延迟和重试次数的实时告警，从而降低故障修复时间。
在实现上，可以把错误日志分为本地调试日志和远端运维日志两部分；同时，为了保护用户隐私，日志中应避免记录敏感信息。下面是一个简化的日志记录示例。
try {// 可能抛出错误的操作const config = loadConfig();
} catch (err) {logError('CONFIG_LOAD_FAILURE', {message: err.message,stack: err.stack});// 继续执行或进入降级路径
}
3.3 自定义错误类型与统一错误接口
通过自定义错误类型，可以在 catch 处统一识别并路由错误。例如，定义一个 AppError，携带错误码、上下文和可本地化的提示信息。这样可以让业务层对错误有一致的处理策略，而不依赖具体的实现细节。
自定义错误类型的要点是：保持向后兼容性、附带上下文、以及提供友好的提示内容。下面是一个自定义错误的示例。
class AppError extends Error {constructor(message, code, context) {super(message);this.name = 'AppError';this.code = code;this.context = context;}
}try {// 业务逻辑throw new AppError('无效的订单状态', 'ORDER_INVALID', { orderId: 123 });
} catch (err) {if (err instanceof AppError) {logError(err.code, { message: err.message, context: err.context });} else {logError('UNKNOWN_ERROR', { message: err.message });}
}
4. try-catch 在异步环境中的注意点
4.1 同步代码与异步代码的错误处理区别
在异步场景中，错误可能在不同的“事件轮次”发生，因此简单地将 try-catch 放在某个区域并不能覆盖所有情况。异步错误需要在各自的调用点进行捕获，或者将错误通过 Promise 链路向上传递，最终由一个统一的入口处理。
常见的做法是：在异步函数内部使用 try-catch，并在 catch 中将错误重新抛出、转译或进行全局处理。这样可以保持错误语义的一致性。
4.2 async/await 的错误处理
使用 async/await 时，异常会被捕获在 catch 块中，类似同步代码的结构。这让异步代码的可读性和可维护性大幅提升。为了避免未处理的 Promise，在入口处设置全局未捕获错误处理也很常见。
async function getData() {try {const res = await fetch('/api/data');if (!res.ok) throw new Error('请求失败');return await res.json();} catch (err) {// 统一处理或抛出throw err;}
}getData().catch(err => {console.error('外部捕获到未处理的错误：', err);
});
4.3 Promise 链中的错误处理
在不使用 async/await 的情况下，Promise 链中的错误需要通过 catch 来捕获。若链中某一步抛出错误，后续的 then 不会执行，直接进入最近的 catch。
为了提升鲁棒性，可以对关键阶段添加独立的 try-catch 逻辑，或者在链尾部提供一个统一的错误处理分支。下面是一个典型的 Promise 链式错误处理示例。
loadUser().then(user => fetchProfile(user.id)).then(profile => renderProfile(profile)).catch(err => {// 全链路的错误处理入口console.error('链路出错：', err);});
5. 常见误区与优化技巧
5.1 不要滥用空的 catch
空的 catch 会掩盖真实错误的来源，导致排错困难。在捕获异常后应尽量保留错误信息、并决定是否重新抛出或进入降级路径。若捕获后不进行处理，应该将错误重新抛出，确保上层有机会感知问题。
一个错误的处理策略是：对不同错误采取不同的处理动作，避免统一吞掉所有错误。这样既可以稳定运行，又能精准反馈问题来源。
try {const r = mightFail();
} catch (err) {// 不要简单吞掉，至少记录日志logError('UNHANDLED_ERROR', { message: err.message, stack: err.stack });throw err; // 如需上抛，由上层统一处理
}
5.2 面向用户的错误提示与用户体验
对最终用户而言，错误信息需要简洁、可理解且不泄露实现细节。通常做法是将技术性错误信息映射为友好的提示，并在必要时提供重试按钮、联系支持等交互。良好的错误提示能显著提升用户信任度。
同时，前端应尽量避免在 UI 层直接暴露原始错误堆栈，而是通过错误码进行本地化描述，并在后台结合日志系统分析问题根因。
try {const data = await fetchData();
} catch (err) {// 显示友好信息给用户showToast('系统异常，请稍后再试');// 同时将错误上报以便诊断reportError({ code: 'DATA_FETCH_FAILED', detail: err.message });
}
5.3 与资源清理的结合点
在 finally 块中进行资源清理，是一个常见且稳健的模式。无论是否发生异常，释放资源、取消订阅、关闭连接等清理操作都应执行，避免内存泄漏或不一致状态。
最终的错误处理策略应将 错误捕获、日志记录、资源清理和 用户体验结合起来，形成一个可重复、可测试的流程。下面给出一个带 finally 的示例。
try {openResource();// 可能抛出错误的操作const result = computeImportantValue();
} catch (err) {console.error('处理过程出错：', err);
} finally {// 不论成功与否都执行清理closeResource();
}
