个人认为，如果在公司的野蛮生长阶段，一些基础类库不做约束，很可能“埋坑”，形成技术债务，最终为此付出代价。本文讲解一个最简的日志打印规范。
事实上，日志打印规范互联网上已有很多，但大多比较冗长（记不住），也不太契合我们团队（关注点不契合）。
所以，我又造了个轮子，写了个简单易懂、容易记的“最简日志打印规范”，后续随着团队实力的增长，和项目的演进，会逐步增加新的条例。
1. 日志打印组件
日志组件有很多，日志门面的选择有：Slf4j、Apache Commons Logging等。
日志的实现更多，有：log4j、logback、log4j2、Java Util Logging(jul)、Jboss Logging等。
目前，我们使用Slf4j作为日志门面，logback作为日志实现。
2. 日志打印级别
日志的级别有很多，我们一般只用四个。日志级别由低到高DEBUG - INFO - WARN - ERROR。
- DEBUG（调试）：开发调试日志。一般来说，在系统实际运行过程中，不会输出该级别的日志。因此，开发人员可以打印任何自己觉得有利于了解系统运行状态的东东。不过很多场景下，过多的DEBUG日志，并不是好事，建议是按照业务逻辑的走向打印。打个比方，打印日志就像读书时划重点，如果导出都是重点，也就失去了重点。
- INFO（通知）：INFO日志级别主要用于记录系统运行状态等关联信息。该日志级别，常用于反馈系统当前状态给最终用户。所以，在这里输出的信息，应该对最终用户具有实际意义，也就是最终用户要能够看得明白是什么意思才行。
- WARN（警告）：WARN日志常用来表示系统模块发生问题，但并不影响系统运行。 此时，进行一些修复性的工作，还能把系统恢复到正常的状态。
- ERROR（错误）：此信息输出后，主体系统核心模块正常工作，需要修复才能正常工作。 就是说可以进行一些修复性的工作，但无法确定系统会正常的工作下去，系统在以后的某个阶段，很可能会因为当前的这个问题，导致一个无法修复的错误（例如宕机），但也可能一直工作到停止也不出现严重问题。
3. 日志打印场景
在我们的系统中，不同的日志级别的打印场景大致如下：
| 日志级别 | 打印场景 |
|---|---|
| DEBUG | 调试日志。目前管理相对宽松，我们暂时没有严格要求。 |
| INFO | 业务日志。我们用来记录业务的主流程的走向。 |
| WARN | 警告日志。一般来说，发生对整个系统没什么影响的异常时，可以打印该级别的日志。 |
| ERROR | 错误日志。级别比较高，如果发生一些异常，并且任何时候都需要打印时使用。 |
4. 日志使用方式
- 使用的API
|
public static final Logger LOGGER = LoggerFactory.getLogger(MyRealm.class);
|
我们使用的日志门面是slf4j，使用时应面向接口编程，LOGGER/LoggerFactory应该都是slf4j的API。
严禁直接使用日志实现包。原因大致有两点，第一是面向接口编程更优雅，这点不必说明；第二，举个例子，因为log4j已经几年不更新，老的项目可能使用了log4j，现在想要换用logback或者log4j2，如直接使用log4j的API，不利于选型更换与API的统一（当然，非要用也没关系，有个log4j-over-slf4j的适配器。但接口不统一，总感觉哪里不对劲）。
- 禁止字符串拼接
例如：
|
LOGGER.debug("当前用户是:" + user + ",传入参数是:" + userId);
|
严禁使用字符串拼接的方式打印日志，可读性、可维护性都比较差。
建议的写法如下：
|
LOGGER.debug("当前用户是:{},传入参数是:{},返回值是:{},用户信息:{}", a,b new Object[]{token, userId, userInfo, authcInfo});
|
因为我们使用的是Slf4j，Slf4j有占位符填充的功能。多个占位符可放在Object数组中。
- 无需使用级别判断
不优雅示例：
|
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("当前用户是{}", token);
}
|
以前，为了性能，我们常常在打印日志之前判断一下。
使用Slf4j后，我们可以写成如下形式就OK了。
|
LOGGER.debug("当前用户是{}", token);
|
当然，如果依然使用字符串拼接的方式，还是得判断一下级别的。