关于日志打印的几点建议

日志的打印在软件开发过程中必不可少，一般分为两个大类：

操作日志：主要针对的是用户，例如在Photoshop软件中会记录自己操作的步骤，便于用户自己查看。

系统日志：主要针对的是软件开发人员（包括测试、维护人员），也就是说这部分的日志用户是看不到的，也就是我们通常所说的debug日志。

操作日志相对比较好理解，用户做了什么就记录什么；而打印系统日志则很多人无从下手，往往一般有下面几个方面：

Where：不清楚在何处打印日志
Who：不清楚打印什么级别的日志
What：不清楚日志应该包含什么内容
　　
WHERE
　　1.程序入口
　　在入口打印日志是因为这个时候传递进来的参数没有经过任何处理，将它打印在日志文件中能一眼就知道程序的原始数据是否符合我们的预期，是不是传递进来的原始数据就出现 的问题。

2.异常捕获
　　在异常打印出详细的日志能让你快速定位错误在哪里，例如在程序抛出异常捕获时，在平时我们经常就是直接在控制台打印出堆栈信息e.printStackTrace()，但在实际的生产环境更加艰苦，更别说有IDE来让你查看控制台信息，此时就需要我们将堆栈信息记录在日志中，以便发生异常时我们能准确定位程序在哪里出错。

3.重要信息
　　这一点可能很宽泛，因为不同的业务逻辑重点可能并不一样，例如在有的重要参数不能为空，此时就需要判断是否为空，如果为空则记录到日志中；还有的例如传递进来的参数经过一系列的算法处理过后，此时也需要打印日志来查看是否计算正确。但切记，尽量不要直接在for循环中打印日志，特别是for循环特别大时，这样你的日志可能分分钟被冲得不见踪迹，甚至带来性能上的影响。

WHO
日志打印通常有四种级别，从高到底分别是：ERROR>WARN>INFO>DEBUG。应该选用哪种级别就是个很重要的问题。

首先明确日志级别中的优先级是什么意思，在你的系统中如果开启了某一级别的日志后，就不会打印比它级别低的日志。例如，程序如果开启了INFO级别日志，DEBUG日志就不会打印，但不打印不代表不产生,通常依旧会记录在文件内容中，这在后面会提到。通常在生产环境中开启INFO日志。

以下是我的个人理解：

INFO
　　程序入口，这能让开发人员确认参数是否为自己所为。
计算结果，测试关心的程序的输出结果是否符合预期，那么对于计算过程不应该关心，仅给出计算结果就能判断是否符合预期。
DEBUG
　　对于DEBUG级别，我认为更关心的是过程，以及更为具体的相关信息，因为帮助它的定位在于帮助开发人员定位bug，定位bug就需要较为详细的参数信息才能定位。例如对于某个具体的算法过程，可以使用DEBUG打印，开发人员不仅关心结果，同时在结果不正确时应该能根据DEBUG日志查询计算过程是否出现偏差

WARN
　　某个不常走到的分支，对于常规的操作是不应该打印WARN日志的，只有在满足某个条件才能走到的分支，且这个分支引起了“警觉”，此时就应该打印WARN日志。

ERROR
　　毫无疑问出现错误，程序不能继续运行下去就应该打印ERROR日志，这个错误并不是业务上的错误。例如，新增某个用户发现已经存在时，此时虽然新增失败，但不能说程序出现错误就打印ERROR日志；在删除某个用户发现用户已经被锁定时，此时也不能说因为程序不能按照删除的逻辑继续运行下去就应该打印ERROR日志。

WHAT
　　应该打印什么内容？打印的内容一定要从实际出发。也就是说如果在实际的生产环境中，你的用户量很大，日志在不停地刷新，如何定位某个用户的整个登录以及后续的操作呢？当然就是根据用户名来跟踪。所以打印内容的第一要素就是要能便于定位；定位过后也许用户在好几个模板中进行操作，还是定位，这个时候定的是模块的位；还有一点当然就是用户操作时的具体参数；最后一点就是用户干了什么。

总结就是，[id, module, params, content]（关键字，模块，参数，内容）。

以上就是对日志打印的几点建议，说的不全面，抛砖引玉。