1. 错误处理的常见误区与危害
上周五下午，后端群里一个刚来半年的同事发了一张截图，问了一个看似简单却极具代表性的问题："这个接口偶尔返回空数据，但日志里啥报错都没有，怎么排查？"我看了他贴出来的代码，问题立刻浮出水面：
javascript复制async function getUserOrders(userId) {
try {
const orders = await orderService.findByUser(userId);
return orders;
} catch (error) {
return []; // 🚨 把错误吞了，还伪装成"没有数据"
}
}
这段代码表面上看起来人畜无害，实际上却是一个完美的"犯罪现场"。无论发生什么错误——数据库连接超时、权限校验失败、用户ID不存在——它都会返回一个空数组。前端收到空数组，理所当然地认为用户没有订单，而实际上可能是系统出现了严重问题。
1.1 错误被吞噬的严重后果
这种错误处理方式带来的问题远比想象中严重：
- 调试难度指数级上升：原本通过日志就能立即定位的问题，现在需要花费数小时甚至数天来猜测和排查
- 问题被掩盖：系统在默默积累问题，直到用户投诉才被发现
- 测试环境无法复现：测试环境通常运行良好，难以模拟生产环境的复杂情况
- 数据一致性被破坏：系统表现出错误的行为，但没有任何告警
更糟糕的是，这种现象在项目中极为普遍。随便搜索一下代码库中的catch语句，你会发现大量类似的"错误处理"：
python复制# Python版本的完美犯罪
try:
result = process_payment(order)
except Exception:
pass # 当事情没发生过
这种代码在审查时往往被忽略，因为它看起来"无害"。但实际上，它可能导致支付处理异常、重复扣款、第三方接口失败等问题被完全忽略。
1.2 错误处理的常见反模式
在实际项目中，我总结了几种最常见的错误处理反模式：
- 完全忽略型：
catch块中什么都不做，或者只有pass/continue - 日志敷衍型：只记录
"出错啦"这样毫无意义的日志信息 - 默认值伪装型：返回空数组、空对象或默认值，假装一切正常
- 异常泛化型：捕获过于宽泛的异常类型（如
Exception），丢失具体错误信息
这些反模式带来的后果是惊人的：根据我的经验，约20%的系统错误从未出现在日志中，它们被代码"处理"掉了——这里的"处理"实际上是掩盖问题。
2. 错误处理的正确原则与实践
2.1 错误处理的两大核心原则
基于多年项目经验，我总结出错误处理的两条黄金原则：
原则一：你处理不了的错误，就不要处理
业务层代码通常不知道如何处理底层错误（如数据库连接超时）。这时，正确的做法是让错误向上传播，由全局错误处理器统一处理。
javascript复制// 不在业务层吞错误。让它爆出来
async function getUserOrders(userId) {
// 出了异常？直接抛出去。上游会有全局拦截器处理
const orders = await orderService.findByUser(userId);
return orders;
}
// 在应用入口统一兜底
app.use((err, req, res, next) => {
// 完整记录：异常类型、消息、堆栈、请求上下文
logger.error({
message: err.message,
stack: err.stack,
url: req.originalUrl,
userId: req.user?.id
});
res.status(500).json({ error: '服务异常，请稍后重试' });
});
这种模式不仅减少了代码量（不需要每个函数都写try-catch），还确保了所有错误都能被统一记录和处理。
原则二：如果你要处理错误，就提供足够的信息
确实有些场景需要在业务层处理特定错误（如降级逻辑）。这时，你的catch块至少应该做到：
java复制public UserProfile getUserProfile(Long userId) {
try {
return userRepository.findById(userId)
.orElseThrow(() -> new UserNotFoundException(userId));
} catch (UserNotFoundException e) {
// 1. 记清楚：谁出了什么错
log.warn("用户不存在, userId={}", userId);
throw e; // 2. 该爆还是爆——让调用方知道
} catch (Exception e) {
// 3. 意料之外的错误：完整记录上下文
log.error("获取用户信息时发生未知异常, userId={}", userId, e);
throw new ServiceException("用户服务暂时不可用", e);
}
}
与之前看到的"假装处理"版本相比，这个实现有几个关键改进：
- 区分不同类型的异常
- 每条日志都包含足够的上下文（如userId）
- 保留了完整的错误堆栈
- 对于无法处理的异常，仍然向上抛出
2.2 分层错误处理策略
在实际项目中，我推荐采用分层错误处理策略：
- 基础设施层：处理技术性错误（数据库、网络等），记录详细日志
- 业务逻辑层：处理业务规则相关的错误，提供有意义的错误信息
- 表现层：统一格式化错误响应，保护敏感信息不泄露
- 全局层：兜底处理所有未捕获异常，确保系统稳定性
每一层都有明确的职责，不越界处理自己无法处理的错误。
3. 实战中的错误处理技巧
3.1 日志记录的最佳实践
好的错误日志应该包含以下要素：
- 时间戳：精确到毫秒
- 错误类型：具体的异常类名
- 错误消息：简明描述问题
- 堆栈跟踪：完整的调用链
- 业务上下文：相关的业务ID、用户信息等
- 环境信息：服务器、线程、请求ID等
示例（Node.js）：
javascript复制logger.error({
message: '订单查询失败',
error: err, // 包含类型、消息和堆栈
userId: ctx.user.id,
orderId: ctx.params.orderId,
requestId: ctx.requestId,
timestamp: new Date().toISOString()
});
3.2 错误分类与处理策略
不是所有错误都应该以相同方式处理。我通常将错误分为几类：
| 错误类型 | 特点 | 处理策略 | HTTP状态码 |
|---|---|---|---|
| 客户端错误 | 用户输入问题 | 直接返回错误详情 | 400-499 |
| 业务规则错误 | 违反业务规则 | 返回明确的业务错误码 | 409/422 |
| 依赖服务错误 | 第三方服务失败 | 记录详细日志，考虑重试/降级 | 502/503 |
| 系统错误 | 代码bug或配置问题 | 记录详细日志，告警 | 500 |
3.3 错误传播与包装
在多层架构中，错误传播需要特别注意：
- 不要丢失原始错误：包装异常时保留cause
- 适当转换错误类型：将技术错误转换为业务错误
- 添加上下文信息：在错误传播过程中补充有用信息
Java示例：
java复制try {
return repository.findById(id);
} catch (SQLException e) {
throw new BusinessException("查询用户失败", "USER_QUERY_FAILED", e);
}
JavaScript示例：
javascript复制try {
await orderService.process(order);
} catch (err) {
throw new Error(`处理订单${order.id}失败`, { cause: err });
}
4. 常见问题与解决方案
4.1 如何处理预期中的"错误"？
有些情况技术上会抛出异常，但业务上是正常情况（如"用户不存在"）。建议：
- 优先使用返回码：对于预期中的情况，返回特殊值比抛异常更合适
- 使用特定异常类型：如果使用异常，定义专门的异常类
- 明确文档：在API文档中说明哪些情况会抛出什么异常
4.2 异步代码的错误处理
异步代码的错误处理容易遗漏，特别是：
- Promise链中的catch：确保每个链都有错误处理
- 事件监听器的错误：为EventEmitter添加error监听器
- setTimeout/setInterval：内部的错误不会传播到外部
解决方案：
javascript复制// 不好的做法
async function updateUser(user) {
// 错误会被静默忽略
saveToCache(user).catch(console.error);
return db.save(user);
}
// 好的做法
async function updateUser(user) {
await db.save(user);
await saveToCache(user).catch(err => {
logger.error('缓存更新失败', err);
metrics.increment('cache.update.failed');
});
}
4.3 如何避免过度错误处理？
过多的try-catch会让代码难以维护。建议：
- 只在你知道如何处理的层处理错误
- 使用中间件/拦截器处理通用错误
- 对于不可恢复的错误，尽早失败
4.4 错误处理与事务
在数据库事务中，错误处理需要特别注意：
- 明确事务边界：知道事务从哪里开始，到哪里结束
- 正确处理回滚：发生错误时确保回滚
- 避免嵌套事务陷阱：了解你使用的ORM/驱动的事务行为
示例（使用Knex）：
javascript复制try {
await knex.transaction(async trx => {
await trx('accounts').where('id', 1).decrement('balance', 100);
await trx('accounts').where('id', 2).increment('balance', 100);
});
} catch (err) {
logger.error('转账失败', err);
throw new Error('转账处理失败，请重试');
}
5. 错误监控与改进
5.1 建立错误监控体系
仅仅记录错误是不够的，还需要：
- 错误聚合：将相似错误归类
- 告警机制：对关键错误实时告警
- 趋势分析：跟踪错误率变化
- 影响评估：评估错误对业务的影响
5.2 从错误中学习
定期进行错误复盘：
- 根本原因分析：不只是修复表面问题
- 模式识别：发现重复出现的错误模式
- 预防措施：修改开发流程或架构防止类似错误
- 知识共享：将经验教训分享给团队
5.3 错误处理检查清单
在代码审查时，我通常会检查这些点：
- 每个catch块是否提供了足够的信息？
- 是否捕获了过于宽泛的异常类型？
- 是否在正确的层级处理错误？
- 是否保留了原始错误信息？
- 是否有错误被静默忽略？
- 错误日志是否包含足够的上下文？
- API错误响应是否一致且有帮助？
回到开头的故事，那位同事修改代码后发现，那个接口从上线第一天开始，数据库查询就一直在间歇性超时——平均每天17次。只是因为所有错误都被return []吞掉了，所以一直没人发现。这个问题已经默默存在了三个月。
这个案例生动地说明了不当错误处理的代价：它不会让问题消失，只是把问题隐藏起来，让解决成本变得更高。好的错误处理不是让代码不报错，而是让错误在发生时能够被快速发现、理解和修复。