后端编码规范系列（十二） 日志记录打印

上文《后端编码规范系列（十） 链路日志打印》我们提到了全链路日志打印。日志在我们日常开发过程中是离不开的。所以我们在开发中需要定义如何去打日志。

在我们的规范中，我们对于日志打印的输出位置有如下要求：

1、所有的web 接口需要打印：request ip,request url,request prams,request body,response body
2、初始化参数，所有不管涉及到框架的初始化参数还是自定义参数及其他涉及到参数的地方，都需要把对应的所有参数打印出来，这里的参数包括不仅限于：配置文件的参数，运行时传递的 args 参数，数据库表里配置的业务参数，写死嗯常量参数。
3、异常信息，所有涉及到 try-catch-finally的地方，被 catch 的异常信息需要进行打印，同时全局异常绑定的异常如果触发的话，都必须把异常信息打印出来。
4、流程分支，在代码里面涉及到一些流程分支，例如：if-else if-else 等这样的一些分支，必须打印相关的日志，方便判断流程的走向。
5、核心业务，这里的核心业务就比较模糊了，主要是根据开发人员时间情况进行打印，例如支付的时候，需要打印的有：准备支付，xxx 应该支付多少，扣除优惠券多少，支付成功了多少，是否分配wms等。这些主要是根据实际的业务进行判断。
6、第三方远程调用，这里不管是调用第三方，还是使用 feign 调用微服务的某个模块我们都称为第三方，需要强制打印，request url,request prams,request body,response body

以上的面大概都能覆盖到对应的业务场景。大家可以总结下。

接下来我们再介绍下打印日志的级别，这里主要是由于开发环境，测试环境，灰度生产环境，准生产环境要求的打印日志级别不一样，所以需要进行取舍，对于我们来说如何规范这块呢？下面我们列举下：

1、error：比较严重的问题，影响正常业务运行
2、warn：对业务影响不大，但是需要开发注意
3、info：用于日常排查问题的关键信息，接口入参和出参等等
4、trace：详细信息，日志文件级别
5、debug：仅仅用于开发或者测试查看重要的内部逻辑细节，但是和线上的业务关系不是特别密切

我们是根据上诉5个场景进行揣摩的，这里需要开发人员有一定的思考觉悟能力。

以上就是我们内部对于日志打印的相关要求。