晚上同事因为一个调用接口参数问题搞了很久，并且也打印出了接收到的base64编码和处理后到参数，并且就是没有直接查看一下日志中base64编码的参数就判定传入的参数有问题浪费了好长时间排查问题，结果最后发现时处理输入参数时一个字符串替换引起的，其实传入的处理前被编码的参数是正常的，处理后的参数就异常了。
但因为没做处理前编码参数的确认导致花好长时间定位排查问题。如果当初能细心一步步确认多好。
同样另外的问题因为tomcat服务启动失败，直接设置环境变量，用一个新tomcat服务就能好，但因为想直接改tomcat脚本导致各种尝试结果因为某些未知的原因还是不行。
这些都是解决问题的经验教训，但这又有多大意义呢？因为这些问题看上去都是小心正常操作不应该出现的，但结果往往因为某一个细节步骤的缺失导致出现问题，然后又因为解决问题方向错误导致错误花费时间越来越多。
出现这个问题的时候让自己静下来，再从头观察一下问题的前因后果，或许就能更高效的解决问题。
