在开发过程中，打印日志是必不可少的，因为日志关乎于应用的问题排查、应用监控等。现在打印日志一般都是使用 slf4j，因为使用日志门面，有助于打印方式统一，即使后面更换日志框架，也非常方便。在 《Java 开发手册》中也有相关的规约。
所以在开发中，一般使用下面这种方式来打印日志。
LOGGER.info("print: {}", "this is the log");
不过有的应用会将 LOGGER 再封装一下，最终写成：
LoggerUtil.info(LOGGER, "print: {}", "this is the log");
本文的主要内容是讨论为什么要封装，有没有必要封装，以及怎样封装，如果小伙伴有更好的建议，可以提出，进行互相学习。
为什么要封装
很多人觉得 slf4j 本来就是日志门面，已经封装的很好了，为什么要多此一举，再额外封装一个 LoggerUtil 呢？
其实这块也是在开发规范中有说明的：
如果不进行封装，则会写成下面这种：
if (LOGGER.isInfoEnabled()) {
LOGGER.info("print: {}", "this is the log");
}
所以，一般封装是将 if 判断这块逻辑统一封装为一个工具类。
可能到这里还有小伙伴不是很理解为什么要加 if 判断，可以看下下面这段代码：
可以看出转换逻辑这块相对比较复杂、耗时，在这里只是模拟的场景，实际使用可能会有其他情况，比如打印方法的出参入参、计算耗时等：
LOGGER.info("xxx 方法请求参数为：{}", JSON.toJSONString(req));
LOGGER.info("xxx 执行耗时：{}ms", System.currentTimeMillis() - startTime);
在某些场景下为了提高性能，需要关闭日志，比如大促，秒杀等等。
说到这里相信小伙伴已经看出问题了，因为这样写的话，当我关闭日志打印时，只是关闭了磁盘输出，但是耗时逻辑依然会继续执行。
# 日志级别调整到 error
logging.level.com.liuzhihang=error
这也是为什么在开发规范中建议大家手写判断，虽然日志框架中帮我们进行了判断，那只是避免了打印输出日志，实际上像组装日志，序列化实例对象等等还是会被执行的。
当然如果当前应用只有个位数的 tps 或者 tpm 那完全没必要考虑这些，也没必要因噎废食，正常使用就行。
该怎样封装
为了避免每次都要 if 判断的问题，会将 if 模块封装为工具类：
上面的封装，有效避免了每次都需要进行判断，只需要将代码中的打印日志换成 LogUtil 即可：
但是这种情况只能避免打印既有参数时的 if 判断，对方法类型的没有作用，这里就需要使用 Supplier：
实际使用效果：
以上仅为一种封装方式，其他的封装可以自行考虑，比如整个日志框架都封装。
其他使用
这部分封装在 log4j-api-2.17.2.jar 中也有所体现，只不过 slf4j 里面并没有封装 Supplier 支持，详细实现可以自行阅读源码。
那为什么 slf4j 不支持，其实也是有讨论的，可以看 issue #70，里面进行了一系列讨论。
最终结果是在 2.0 支持了 Fluent Logging API 语法。
slf4j 2.0 使用#
<dependency>
<groupId>org.slf4jgroupId>
<artifactId>slf4j-apiartifactId>
<version>2.0.1version>
dependency>
<dependency>
<groupId>org.slf4jgroupId>
<artifactId>slf4j-simpleartifactId>
<version>2.0.0version>
dependency>
按照官方文档的使用案例直接使用即可：
logger.atDebug()
.setMessage("Temperature set to {}. Old value was {}.")
.addArgument(() -> t16()).addArgument(oldT)
.log();
为什么要这样写，只能说是人家的 API 设计就是如此，当然也有其他的考虑，可以看看 github issue。具体使用哪种，用不用封装等等，这些都是根据自己的实际情况来使用。