前言
同志们在开发项目的写后端接口的过程当中是不是很多的调用方法是实现层已经实现了的。
我们只需要继承jar包封装好的实现类就可以轻松的实现我们的业务逻辑，这样其实大大的减轻了我们的开发效率。
其实这样挺好的，但是我们使用的时候一定要瞅准自己的业务逻辑，否则会给你带来意想不到且非常麻烦的问题，甚至带来的损失有可能也是无法估量的。
这不在前不久涉及金额消费的项目中，我就出现了严重的Bug。
究竟是怎么一回事儿呢，带大家一探究竟！
起因
在项目一切正常进行的过程当中，之前我们的业务是用户在平台下单消费以后扣除消费余额以后，这个消费明细是直接进行订单详情的记录就行了。然后根据业务的调整，我们需要做一个用户消费明细的表并且用户首次下单需要绑定站点的逻辑，也就是用户消费记录。
用户下单的同时我们是需要记录用户消费之前的余额，消费余额和用户消费完成后的剩余余额等这些信息的。相关的表结构很简单
这里创建的表是没有什么问题的。我就按照业务进行正常开发，修改创建订单的业务逻辑了。修改业务逻辑其实也挺简单的，就是给用户钱包消费记录表中进行数据的记录后然后更新用户绑定就行了，很简单的一个插入方法就搞定了，我的代码是这样的：
图1：
图2：
图3：
大家看到问题了没，代码执行完图2以后，其实已经将用户的余额表更新为消费后的金额了，然后意外就出现在图3当中，此时，图三的user类中的balance还是图1中的旧数据。但是直接调用封装的方法进行了更新，结果显而易见，把余额又给更新回去了。
这麻烦大了去了，当时已经上线，而且用户也已经进行了使用。这造成了将近500多用户数据的余额都是错乱的，这无疑是车祸呀！！！我真的是慌了。
修复
我们后端发现以后赶紧修改图3BUG并且紧急修复数据，索幸小程序当时的使用不在高峰期，要不然真的要嘎了。不幸中的万幸，在组长的带领下经过长达3个多小时的奋战，终于将数据修复好了。
教训
经过此次也是收到了很大的教训，告诫自己： 首先在业务逻辑写完以后，一定一定要进行本地的测试，并查看数据库的数据是否正确。 其次在开发的时候，如何拿不准的地方也要请教别人的。
希望大家在以后得开发过程中引以为戒！此次分享就到这里，先去给人家买红牛了！！！
