初期，我们的系统比较简单，在这个过程中，加上大家平时都不注意，所以Logger日志一直是打印的随心所欲，什么是随心所欲的，就是大家想在哪里打日志就在哪里打印日志，想输出什么就输出什么，毫无规范可言，在系统的流量和业务量变得越来越复杂的情况下，良好的日志才能帮助我们更快地找到问题，更好地解决问题。
首先来看一下比较常用的Logger日志级别（部分未列出）:
error - 运行期错误日志记录，应该有专门的error日志文件。；warn - 警告信息，如程序调用了一个即将作废的接口，接口的不当使用，运行状态不是期望的但仍可继续处理等；info - 有必要的事件信息记录。debug - 调试信息，业务处理进行状态，当前的变量值等；trace - 一些更详细的跟踪信息；鉴于我们是一个金融系统，流量还是不算很大，我个人认为debug级别和info级别可以统一归为info级别下打印，这是考虑到现在系统稳定性不够，处于一个快速迭代开发的过程中，线上问题可能随时都有，所以将业务流转与部分变量值打印出来还是很有必要的。error记录错误日志，但如果错误是预期会发生的，并且已经有了其他的处理流程，则建议使用warn级别。例如在try-catch中catch块里处理后继续流程的日志记录。
1.Logger对象的定义：
<strong>private static final Logger logger = LoggerFactory.getLogger(Test.class);</strong>2.日志中不出现计算或方法调用，防止在打印日志的时候报错。
之前在上家公司的时候就确实出现过因打印日志而系统RunTimeException的，不应该出现。
3.try-catch如果往外抛出，则不应该打印异常信息。
try { throw new Exception(); } catch (Exception e) { logger.error("xxxxxx", e); throw e; }这样的处理解释不合适的，因为抛出去的异常，一般情况下你肯定会记录。（当然如果你不记录，那么我就搞不懂为什么你要抛出去了）。
4.如何打印error Log
log.error("xxxxxxxxxxxx", e);这种比较推荐，当然在实际过程中我也看到有同事用了其他的方式，形如：
logger.error("xxxxxx", e.getStackTrace());可以是可以，这种打印出来的stackTrace比较丑。。。用一下你就知道。
Log4j、Log4j2的源码中对于异常Exception的处理时这样的。
所以【占位符小于实际的参数数量时会把最后一个设置为Throwable】，即可以正常打印error。
log.error("xxxxxxxxxxxx{}","第一个参数" e); //可以正常打印 log.error("xxxxxxxxxxxx{},{}","第一个参数" e); //不能正常打印，因为占位符和参数数量一样private void initThrowable(final Object[] params, final int argCount, final int usedParams) { if (usedParams < argCount && params[argCount - 1] instanceof Throwable) { this.throwable = (Throwable) params[argCount - 1]; } else { this.throwable = null; } }
5.日志记录建议用英文（这点没有依据）。
用中文除了占用大点好像没什么不好，但是还是建议用字母。
6.http请求时应该打印 url ,param, get/post，statusCode,ret,timeUsed等关键字段。
反正我吃过没打印这些的亏，还不是我写的代码。说出来都是泪。
7.相对6，别人调用接口的时候应打印 入参，请求用时，返回值，来源等关键字段。
8.分支流程如果必要再外层打印参数，可以知道具体走了哪个流程。
以上都是日常工作的痛点，希望自己可以在今后工作中也以此为标准。
