欢迎阅读我的文章！更多精彩内容，欢迎关注：
• B站主页：小枫Geek
• 微信公众号：Procode  

---

 

 

        在很多 Spring Boot 项目中，日志几乎是开发和运维最重要的“观察窗口”。系统运行时发生了什么、接口为什么报错、数据库为什么异常，大多数时候都只能通过日志来还原现场。

        但现实情况是，很多项目的日志设计非常混乱： 有的地方几乎什么都不打印，有的地方却到处都是 error 日志。久而久之，日志系统变成了一片噪声森林——真正的问题反而被淹没在一堆无关紧要的错误里。

        于是就产生一个非常实际的问题：在 Spring Boot 项目中，到底什么时候才应该打印 error 日志？这个问题看似简单，但背后其实是日志设计的基本原则。

 

 

1、先理解日志等级

Spring Boot 常见的日志等级包括：

TRACE < DEBUG < INFO < WARN < ERROR

每个等级代表的含义不同：

日志级别	含义
TRACE	最细粒度调试信息
DEBUG	调试信息
INFO	正常运行信息
WARN	警告
ERROR	严重错误

其中 ERROR 是最高级别之一，意味着：系统发生了真正的异常情况，需要开发或运维关注。

如果 error 打印过多，就会出现一个经典现象：所有日志都是 error，就等于没有 error。

 

 

2、什么时候应该打印 error

一个简单的判断原则：只有当系统出现“非预期错误”时，才应该打印 error。

所谓“非预期错误”，通常指：

• 系统异常

• 外部服务异常

• 数据库异常

• 程序逻辑错误

例如：

try {    userService.createUser(dto);} catch (Exception e) {    log.error("create user failed", e);}

这种情况属于：程序执行失败，并且需要排查问题。

因此适合使用 error。

 

 

3、业务校验失败不要使用 error

很多项目里有一种非常常见的误用。

例如：

if (user == null) {    log.error("user not exist");}

这个其实并不是系统错误，而是：正常业务逻辑。

用户不存在可能是用户输入错误，也可能是数据不存在，这属于业务校验。

更合理的写法是：

log.warn("user not exist");

或者干脆不打印日志。

因为如果每天有大量用户查询不存在的数据，日志就会被刷满。

 

 

4、参数校验失败不应该打印 error

例如接口参数错误：

if (StringUtils.isBlank(username)) {    log.error("username is empty");}

这种情况其实是 客户端输入错误，而不是系统错误。

更合理的方式是：

throw new BusinessException("username is empty");

或者：

log.warn("invalid request param");

否则在高并发系统中，很容易出现：error 日志被无效请求刷满。

 

 

5、捕获异常但没有影响业务时，不要打印 error

例如某些非核心逻辑：

try {    sendSms(user);} catch (Exception e) {    log.error("send sms failed", e);}

如果短信只是辅助功能，其实不需要 error。

更合理：

log.warn("send sms failed", e);

因为系统核心功能仍然正常。

 

 

6、真正应该打印 error 的场景

在 Spring Boot 项目中，一般有几个典型场景适合使用 error。

1. 系统异常

例如：

catch (Exception e) {    log.error("system exception", e);}

系统出现未预期异常。

 

2. 数据库异常

例如：

catch (DataAccessException e) {    log.error("database error", e);}

数据库访问失败。

 

3. 外部服务调用失败

例如：

catch (Exception e) {    log.error("call payment service failed", e);}

外部系统不可用。

 

4. 关键业务失败

例如订单创建失败：

log.error("create order failed, userId={}", userId);

这种情况需要开发人员关注。

 

 

7、一个简单判断方法

当你准备打印 error 日志时，可以问自己三个问题：

1. 这个问题是系统异常吗？

如果是 → 可以使用 error。

2. 运维是否需要关注这个问题？

如果需要 → 使用 error。

3. 这个问题会影响核心业务吗？

如果会 → 使用 error。

否则就不应该。

 

 

8、日志设计的一个经验

在很多成熟系统里，error 日志有一个隐含规则：error 日志必须是“可行动的”。

换句话说：

如果看到一条 error 日志，开发或运维应该知道：

• 出了什么问题

• 发生在哪里

• 如何排查

例如：

log.error("create order failed, userId={}, orderId={}", userId, orderId, e);

这样日志才真正有价值。

 

 

 

小结

在 Spring Boot 项目中，error 日志应该非常克制。

可以记住一个简单原则：只有系统真正出错时，才使用 error。

简单对比：

场景	日志级别
调试信息	DEBUG
正常运行	INFO
业务异常	WARN
系统异常	ERROR

当日志等级设计合理时，系统日志会变得非常清晰：

• INFO 看系统运行

• WARN 看业务异常

• ERROR 看系统问题

日志就像系统的“黑匣子”。 如果记录混乱，再先进的系统，也很难找到真正的问题。

-END-