日志打印的正确姿势

一、使用SLF4J门面模式的日志框架

使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一

• 日志门面
  门面模式，也称之为外观模式，其核心为：外部与一个子系统的通信必须通过一个统一的外观对象进行，使得子系统更易于使用。日志门面，是门面模式的一个典型的应用。

• 为什么需要日志门面
  1、每一种日志框架都有自己单独的API，要使用对应的框架就要使用其对应的API，这就大大的增加应用程序代码对于日志框架的耦合性。
  2、为了解决这个问题，就是在日志框架和应用程序之间架设一个沟通的桥梁，对于应用程序来说，无论底层的日志框架如何变，都不需要有任何感知。只要门面服务做的足够好，随意换另外一个日志框架，应用程序不需要修改任意一行代码，就可以直接上线。
  3、因此，日志门面的一个比较重要的好处——解耦。

在软件开发领域有这样一句话：计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。而门面模式就是对于这句话的典型实践。

二、打日志的正确方式

什么时候应该打日志？

• 当你遇到问题的时候，只能通过debug功能来确定问题，你应该考虑打日志，良好的系统，是可以通过日志进行问题定位的

• 当你碰到if…else 或者 switch这样的分支时，要在分支的首行打印日志，用来确定进入了哪个分支

• 经常以功能为核心进行开发，你应该在提交代码前，可以确定通过日志可以看到整个流程

基本格式

• 使用参数化信息的方式:

  logger.debug(" 财务保存线下收款单,收款单号：[{}] ,创建人：[{}]", receiptTaskNo, creatEmp);

• 对于debug日志，必须判断是否为debug级别后，才进行使用:

  if (logger.isDebugEnabled()) {
    logger.debug(" 财务保存线下收款单,收款单号：[{}] ,创建人：[{}]", receiptTaskNo, creatEmp);
   }

• 不要进行字符串拼接,那样会产生很多String对象，占用空间，影响性能。
  反例:

  logger.debug(" 财务保存线下收款单,收款单号：" + receiptTaskNo + "操作人：" + creatEmp);

• 使用[]进行参数变量隔离

  logger.debug(" 财务保存线下收款单,收款单号：[{}] ,创建人：[{}]", receiptTaskNo, creatEmp);

这样的格式写法，可读性更好，对于排查问题更有帮助。

三、通常使用的不同级别的日志

ERROR:

该级别的错误需要马上被处理，当ERROR错误发生时，已经影响了用户的正常访问，是需要马上得到管理员介入并处理的，常见的异常情况有:

• 空指针异常
• 打开配置文件失败
• 所有第三方对接的异常(包括第三方返回错误码)
• 所有影响功能使用的异常，包括:SQLException和除了业务异常之外的所有异常(RuntimeException和Exception)等等
  如果有Throwable信息，需要记录完成的堆栈信息:

  log.error("获取用户[{}]的用户信息时出错", userName, e);

如果进行了抛出异常操作，请不要记录error日志，由最终处理方进行处理：
反例(不要这么做)

  try {
           ....
        } catch (Exception e) {
		    String errorMessage = "收款单审核异常:";
            LOGGER.error("收款单审核异常", e);
            throw new ServiceException(errorMessage,e);
        }

ERROR:

不应该出现但是不影响程序、当前请求正常运行的异常情况:

• 有容错机制的时候出现的错误情况
• 找不到配置文件，但是系统能自动创建配置文件
• 性能即将接近临界值的时候,例如：缓存池占用达到警告线
• 业务异常的记录，危险操作。比如:当接口抛出业务异常时，应该记录此异常

INFO:

系统运行信息

• Service方法中对于系统/业务状态的变更
• 主要逻辑中的分步骤
• 定时任务等

外部接口部分

• 客户端请求参数
• 远程服务调用参数和调用结果

注意：

1. 并不是所有的service都进行出入口打点记录,单一、简单service是没有意义的

 public List<BankInfoRspDTO> queryBankInfoById(Integer id) {
	log.info("开始查询银行信息，id: [{}]" + id);
	List<BankInfoRspDTO> list = mapper.findPageByParam(pageParam);;
	log.info("查询银行信息结束");
	return list;
    }

2. 对于复杂的业务逻辑，需要进行日志打点，以及埋点记录，比如电商系统中的下订单逻辑，以及业务状态变更。

3. 对于整个系统的提供出的接口，使用info记录入参

4. 调用其他第三方服务时，所有的出参和入参是必须要记录的(因为你很难追溯第三方模块发生的问题)

DEBUG

在生产环境中不能打印DEBUG级别的日志，DEBUG级别的日志只能用于开发调试或测试环节，同时在输出DEBUG级别的日志的时候，也应该依据项目组的开发需求打印日志，尽量做到：

• 开发人员和测试人员都能看懂
• 通过阅读DEBUG级别的日志后不需要重现问题，就能准确的定位解决问题

如果代码中出现以下代码，可以进行优化:

//1. 获取用户基本信息

//2. 获取用户休假情况

//3. 计算用户应得薪资

优化后的代码：

logger.debug("开始获取员工[{}]基本信息",user);
logger.debug("获取员工[{}]年的基本性别为[{}]，年龄为[{}]", user, sex,age);

logger.debug("开始获取员工[{}] [{}]年[{}]月休假情况",employee,year,month);
logger.debug("员工[{}][{}]年[{}]月年假/病假/事假为[{}]/[{}]/[{}]",employee,year,month,annualLeaveDays,sickLeaveDays,noPayLeaveDays);

logger.debug("开始计算员工[{}][{}]年[{}]月应得薪资",employee,year,month);
logger.debug("员工[{}] [{}]年[{}]月应得薪资为[{}]",employee,year,month,actualSalary);