1. 为什么我们需要封装错误处理？
在JavaScript开发中，错误处理就像给代码买保险——平时觉得多余，出问题时才知珍贵。我见过太多项目因为糟糕的错误处理而崩溃，也亲手处理过无数因未捕获异常导致的生产事故。try-catch和async/await是现代JS错误处理的基石，但直接使用它们往往会导致代码重复和逻辑混乱。
想象一下这样的场景：你的Node.js服务有50个API端点，每个都用try-catch包裹，里面又套着async/await。当需要统一修改错误日志格式时，你得改50个地方！这就是为什么我们需要封装——把错误处理的脏活集中到一个地方。
2. 基础版：同步代码的try-catch封装
2.1 原始try-catch的问题
典型的同步代码错误处理长这样：
function readFileSync() { try { const content = fs.readFileSync('config.json'); return JSON.parse(content); } catch (error) { console.error('读取文件失败:', error); throw new Error('配置文件加载失败'); } }这种写法有三个痛点：
- 错误日志格式不统一
- 错误类型判断重复
- 业务逻辑与错误处理耦合
2.2 初级封装方案
我们可以提取通用的错误处理逻辑：
function withTryCatch(fn) { return function(...args) { try { return fn.apply(this, args); } catch (error) { handleError(error); // 统一的错误处理 throw error; // 或者返回特定错误对象 } }; } // 使用示例 const safeReadFile = withTryCatch(function() { const content = fs.readFileSync('config.json'); return JSON.parse(content); });提示：这种柯里化方式在装饰器模式中很常见，适合包装纯函数
3. 进阶版：异步代码的async/await封装
3.1 async/await的痛点
异步代码的错误处理更复杂：
async function fetchUser() { try { const res = await fetch('/api/user'); const data = await res.json(); return data; } catch (error) { // 需要区分网络错误、JSON解析错误等 if (error instanceof SyntaxError) { // ... } else { // ... } } }常见问题包括：
- 多层异步嵌套导致try-catch地狱
- 错误类型判断逻辑重复
- 无法统一处理HTTP状态码
3.2 高阶函数解决方案
创建一个异步包装器：
async function withAsync(fn) { try { const result = await fn(); return [null, result]; // 错误优先的风格 } catch (error) { await logError(error); // 异步错误日志 return [error, null]; } } // 使用示例 const [err, user] = await withAsync(() => fetchUser()); if (err) { // 处理错误 }这种"错误优先"的模式在Go语言中很常见，它有几个优势：
- 避免try-catch块
- 明确区分成功/失败路径
- 方便组合多个异步操作
4. 生产级解决方案设计
4.1 错误分类体系
完善的错误处理需要分类策略：
class AppError extends Error { constructor(type, message, originalError) { super(message); this.type = type; // 'NETWORK', 'VALIDATION'等 this.originalError = originalError; this.timestamp = new Date(); } toJSON() { return { type: this.type, message: this.message, stack: this.stack }; } }4.2 可配置的包装器
完整的封装方案应该支持：
function createErrorHandler(options = {}) { return { sync: (fn) => { // 同步函数处理逻辑 }, async: (fn) => { // 异步函数处理逻辑 }, wrap: { // 装饰器风格的API @errorHandler() method() {} } }; } // 配置示例 const { sync, async } = createErrorHandler({ log: true, report: true, format: 'json' });4.3 性能考量
错误处理不是免费的，需要注意：
- try-catch块会影响V8优化
- 过多的错误对象创建增加GC压力
- 同步错误处理比异步更快
实测数据对比（Node.js 16.x）：
| 处理方式 | 每秒操作数 | 内存占用 |
|---|---|---|
| 裸try-catch | 1,250,000 | 15MB |
| 封装同步 | 980,000 | 18MB |
| 封装异步 | 320,000 | 22MB |
5. 实战中的经验教训
5.1 不要过度封装
我曾在一个项目中过度设计错误处理，导致：
- 错误栈信息丢失
- 调试困难
- 性能下降30%
教训是：保持简单，只在必要时添加抽象层。
5.2 错误恢复策略
对于不同类型的错误，应该有不同的恢复方案：
| 错误类型 | 恢复策略 | 重试次数 |
|---|---|---|
| 网络超时 | 指数退避重试 | 3 |
| 权限错误 | 刷新令牌 | 1 |
| 数据校验 | 返回400错误 | 0 |
5.3 日志记录的艺术
好的错误日志应该包含：
- 错误发生的时间戳
- 完整的调用栈
- 相关请求/操作上下文
- 环境信息（Node版本、OS等）
避免记录敏感信息如密码、令牌等。
6. 现代JS生态中的最佳实践
6.1 AsyncLocalStorage的妙用
Node.js的AsyncLocalStorage可以保持异步上下文：
const store = new AsyncLocalStorage(); function withRequestContext(fn) { return async (...args) => { return store.run(new Map(), () => { return fn(...args); }); }; } // 在任何地方都能获取上下文 function logError(err) { const requestId = store.getStore()?.get('requestId'); logger.error({ requestId, err }); }6.2 TypeScript集成
用TS类型增强安全性：
interface ErrorHandlingOptions<T> { onError?: (error: unknown) => T; fallback?: T; } function withErrorHandling<T>( fn: () => Promise<T>, options?: ErrorHandlingOptions<T> ): Promise<T> { // 实现... }6.3 前端错误边界
React中的错误边界模式：
class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError() { return { hasError: true }; } componentDidCatch(error, info) { logErrorToService(error, info); } render() { if (this.state.hasError) { return <FallbackUI />; } return this.props.children; } }7. 测试策略
7.1 单元测试错误处理
使用Jest测试错误场景：
test('should handle network errors', async () => { const mockFetch = jest.fn().mockRejectedValue(new Error('timeout')); const [err] = await withAsync(() => mockFetch()); expect(err).toBeInstanceOf(NetworkError); expect(err.message).toContain('timeout'); });7.2 压力测试
使用Artillery模拟错误率：
scenarios: - name: "Test error handling" flow: - post: url: "/api/checkout" json: items: ["prod-123"] capture: json: "$.error" as: "error" - log: "Error rate {{ $errorsPerSecond }} /s"7.3 混沌工程
故意注入错误验证系统韧性：
const chaos = { inject: (probability = 0.1) => { if (Math.random() < probability) { throw new ChaosError('随机故障注入'); } } }; // 在关键路径调用 chaos.inject(0.05); // 5%的失败率在错误处理这条路上，我最大的体会是：好的错误处理应该像空气一样——平时感觉不到它的存在，但缺了它系统就会窒息。封装不是目的，而是为了更专注于业务逻辑。当你发现自己在重复写相似的try-catch块时，就是该考虑封装的时候了。
