小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
聊聊那些服务器上不易察觉的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会好点
