记一下日志引起的 bug

聊聊那些服务器上不易察觉的 bug，

最近，我一直被一个 bug 烦心，我们有一个数据导出的功能，本来也是补一个不是特别麻烦的问题，但是一直出问题，明明我自己本地接口跑的好好的，但是就在服务器上就一直出问题，我自己看日志也没有出现明显的异常错误，只是会打印我之前 try -catch 的错误，因为我捕捉的异常都是基于 Exception 的，但是服务器上的日志信息，也没有显示异常错误，这时候就一直拖着。

本质： 我能找到问题出现的位置，但是定位不到出了什么异常的问题，一直心里犯嘀咕，感叹生活，

所谓问题都会出现现象，然后我要复现出来之后，按照条件去定位出来问题，

但是我忽略的一点，有的错误异常信息不会抛出来，而我也傻乎乎的，就只要自己的提示，当前导出文件失败。

所以第一步我就从日志上下手，对于日志打印其实还有个比较重要的点，我们为了保证日志的独立性且非侵入性，多数的项目都会使用 slf4j,

因为 slf4j,底层使用的是门面模式的日志框架，很有效的保证个各类的处理结果统一。

我一般也直接答应日志是 info 级别的：

log.info("这就是日志");

但是对于有些错误日志要考虑级别，error、warn、info、debug、trace，

这次，就是因为我直接 try_catch 之后，直接将数据 log.error 展示，结果只是打印了错误信息，

连日志错误异常也看不到；

伤心：

try{//业务代码}catch（Exception e）{log.error("当前导出文件数据失败");}

就是以为就算当前的异常出来了，抛出来之后，我也能捕获到这个问题，但是事实就是，

日志只会显示，--当前导出文件数据失败

没有异常信息，

导致我走了很多弯路，

这里告诫一些新手要打印好自己的日志信息，但是也不要用，自带的 e.printStackTrace();

正确的将具体的错误信息展示出来；

try{  // 业务代码处理}catch(Exception e){ log.error(e.getMessage);  log.error("当前导出文件失败"，e);}

其中 e 就是关键的信息，找到这个，这个问题就找到源头了。

最后找到是关于，Linux 服务商文件临时目录的问题，没有权限去创建文件；

我自己写了一个文件，但是服务器上不支持。

最后考虑是直接将数据写进流，然后经过 response 返回，下载到客户端，就可以了；

总结一下：

日志打印很重要，会用 error 和 e 消息，展示消息用 info，祝你下个 bug 会好点