事情起因
在一个月黑风高的晚上，运维说由于业务流程问题，智能运维告警太多，需要处理，同事就改了一点与业务无关的代码，直接把class文件扔上去。到了早上9点，上游通知整个上午都下单失败，吓得我们赶紧登上系统看，一看确实有问题。。。运维立马回滚到上一个稳定版本，然后我和同事去排查问题原因。
问题排查
因为本地和测试环境的流程是正常的，看样子是没啥问题的，后面模拟昨晚的操作把本地的文件增量上到测试环境上，就报错了，报的是下图的代码和错误。
NoSuchMethodError，找不到这个save方法？？我看本地和服务器都有的......
后面再仔细对比，发现里面内有乾坤。本地和测试环境的工具类居然是不一样的。
本地save方法是有返回值的
测试环境反编译后的save方法是没有返回值的
也就是说本地service调用save是调有返回值的save方法，增量上上去之后就找不到有返回值的save方法。
看了增量上线的class文件，结果得到了实锤。
那么为什么两个文件会不一样呢？？这就关系了打包工具jenkins。由于里面的工具包项目是放上去没有更新过了，可能是很旧的版本，后面我们本地的是新版本......
可以理解成jenkins save方法（测试、生产环境）是A版本，本地save方法是B版本，本地编译出来需要读取B版本的save，但是服务器只有A版本的save，就有问题了
如果一开始就是本地打包上生产，就是一直都是B版本，就算增量上线也是不会发生问题。
如果把jenkins的工具类更新到和本地一样的版本，增量上线也是没有问题。
总的来说就是由于增量上线，踩了jenkins和本地代码不一致的坑。
总结
主要是因为之前是很久以前的项目，没有用maven管理，导致版本不一致的问题发生。而且对于重要的业务修改还是要走正式流程，不踩坑也不知道改了一个无关紧要的代码会影响到关键业务。另外还是不推荐增量上线代码，因为是直接跳过了编译操作，这样会造成上面说的奇怪问题，如果是正常打包就会自动检查方法是否存在。一个问题的发生总是有多个小问题造成的，如果是某个环节做好了也不会发生这个事情，面对生产环境还是要小心谨慎。