前言
最近公司某小伙子做了一个商城的微信支付相关的接口，其中包含退款，在测试过程中发现部分单据没有退款，微信支付提示退款金额跟支付金额不匹配（大于支付金额），检查数据库和调试过程中，发现商品的单价和手工计算出来的总价是跟订单金额匹配的，实在无法确认问题原因最终bug转向我来排查，于是有了此文
排查
由于手工计算出来的金额跟实际支付的金额是能匹配上的，所以一开始我以为是订单已经进行了部分退款，再次全部退款的话肯定会被微信阻止，因为这样的话就会出现超退。
第一步：是否已经部分退款
去微信支付平台排查是否有退款，结果发现并没有退款
由于微信平台没有查询到此单的退款，那么说明不是超退的问题，可能是传入的订单金额有问题，但是大部分单据又可以退款，所以也暂时陷入了僵局，不过为了保险起见，还是去看了一下传参处
第二步：检查传参
检查微信退款方法传参时，看了传入参数，由于微信传参的单位是分，所以看到传参处传入退款总金额代码(int)(100)*商品单价*退货数量（这里只是伪代码，多个商品肯定还要相加计算的）,粗略一看没有问题，仔细一看不对，总价是直接double类型的乘以数量在乘以100再强转为int类型传入的，按照理论上来说是没有问题的，因为我们商品价格都是精确到分的，但是只是理论上，实际上就是Java的double类型有个大坑（不只是Java，JavaScript，c#等很多语言都有这个问题），最终在代码中进行总价计算，发现确定是因为这个原因，导致计算出来的退款金额比应退金额多了1分钱，所以导致退款失败
起因
之所以会发生精度丢失，是因为编程语言在十进制和二进制相互转换时，会出现除不断的问题，就导致了精度丢失
详情可以查看知乎原文，我觉得解释的非常不错
解决办法
解决办法有2种：
第一种是电商行业通常的做法，将所有价格用分来表示，数据库中保存int类型，因为通常情况下，商品价格只需要精确到分，分也是正常电商的最小单位，前端显示时通过将分转化成元来显示，但是后端计算都是分来计算，也就是int型来计算，这样就不会出现精度丢失的问题，当然也可能会出现int最大值的问题，当然一般情况下也可以忽略这个问题毕竟没有几个商品价格或者订单能超过int的最大值了，当然系统订单总价可能会超过，这么单独处理一下就行了
第二种就是使用BigDecimal类进行计算了，由于我们系统一开始就是用元来表示，所以只能用DigDecimal来计算避免精度丢失了，具体BigDecimal的用法可以百度
结尾
通过这次问题，首先要注意就是代码中规范好，所有浮点类型计算的都使用BigDecimal进行计算，并且要写入开发规范文档，其次就是类似于价格这类的，以后最好还是用分来进行处理
