【工作记录】记一次问题排错和解决过程

今天下午配合前端那边联调接口，接口是用部署在服务器上的，但是这个时候，报错了，如何在服务器上排查错误，经历的少，这个过程浪费了不少的时间。所以这次记录一下，保证明天不再犯类似的错误。

一、日志文件的路径和位置

第一个拦路虎：“你以为的日志路径？”

我查看了项目中的路径，又去服务器上看了路径，我就以为是这个/log/live-chat-web-api.log，然后利用swagger调用该方法，发现还是调用不通。最后看了看日志，发现最新日志还是2017年10月份的，所以接下来，我又问了问同事，具体的文件路径，才发现，日志文件的路径是不对的。（浪费了10分钟，教训惨痛）

二、linux系统下查看服务器日志命令不熟悉

 如何实时查看log文件，命令是 ：tail -f  live-chat-module-users.log

还是对于linux命令的每个的含义是什么，不太清楚，所以总是忘记，用到的时候，就得马上查。所以今后一定要牢记，这里也浪费了时间。

三、报错问题不敏感

下面是用swagger做接口测试，报的错误如下：ForI input String :\"string\",很明显的错误信息，输入格式问题。但是因为不太确定，服务器上也找不到，所以我本地服务上也跑了一遍，仍然是报同样的错误。然后我确定应该是数据格式的问题。

本地报错如下：

但是我认真检查了一遍，跟项目中modle的属性对应了一遍，发现全都一样的啊。最后求助于同事，同事一眼就看出来了。是字段LanguageId的问题。model中类型定义如下：

所以swagger中传递的也是string类型。

但是实际上在使用的过程中，languageId是多个int类型数字，用逗号分隔组成的字符串。类似于“1,3,34”匹配而成的字符串，

所以传递的应该是内容是int类型的字符串。

更改之后，问题解决。

启发：

问题很明显，但是没有考虑到多个int类型的拼接。

四、查看报错日志的技巧，如何定位错误

解决了第一个问题，第二个问题又过来了。接口报500，我及时定位了错误，如下图：

根据getAdSwitch 显示行数，是218行，去项目代码中搜索，确定方法位置。然后看代码，要去查找对应appId和platform的数据。然后会从list中获取一条（list.get(0)）,应该是未获取到值，然后导致的空指针。

验证猜想，

用传递的参数去mysql中查询指定的数据，果然数据为空，更改传递的参数，测试成功。

启发：

这个思路过程中还是比较清晰的，继续加油。

四、小结

      下午联调过程中，问题真是百出，感谢同事们的帮助，最后全都解决了。在这个过程中，亲身实践，收获很多，包括对于自己的思路和技术积累。其实想想，问题真的很小，但是就是这么小的问题，自己竟然解决不了，很惭愧。

这个下午，心惊胆战，很难过，又有解决问题之后的喜悦。

   继续加油和努力，既然逃不掉，就抛开脸皮，像汉子一般的向前冲。