php
我是一名从事
php开发的后端人员。在大家的普遍印象里，使用
php的
公司往往不怎么样，人员少、工作量大，项目质量也差。正因为人员流动频繁，组内缺乏严格的规范，于是就产生了下面这个Bug。之前有个项目是三方平台，存在多个供应商参与抽成的情况。比如说，一个订单产生一笔收益，平台抽取相应份额后，可能会有多个服务提供方根据各自提供的数据量来分配剩余的收益。在报表接口处，发现存在这样一个问题：有的订单所有分成累加起来之后会少一分钱。这个问题已经存在一段时间了，一直都没人去处理。我入职之后，这个问题就分配给我来解决。我当时就想，这不是初级开发
面试题里常见的浮点数精度问题嘛，用bc_math函数应该就能搞定。于是，我把接口流程梳理了一遍，中间调用的方法也都点开查看了，结果发现都是用的bc_math函数。那这应该就是中间某个地方的分配逻辑写错了吧。就好比三个人平分一块钱，1除以3等于0.33，最后每个人0.33加起来就少了一分钱。我又重新梳理了接口里的计算规则，发现计算规则并没有问题。其逻辑是先获取所有供应商，然后随机排序一次（大概是为了避免id最大的供应商每条订单都比其他供应商多一分钱），接着按照每个供应商的占比乘以收益，最后一位供应商的收益则是订单的总收益减去已经发放的收益。那几天，我被这个Bug折腾得够呛。反复查看代码、梳理逻辑，手动调用接口查看数据，可就是找不出问题所在。我在函数里加了日志，但这个Bug是偶发性的，根本无法复现。只是偶尔有几个供应商的财务人员反馈说，查看某个月的报表时发现某条数据少了一分钱。这几条少了一分钱的数据，可把他们和我都折磨得不行。直到有一天，我这个人记性不太好，很多函数我只是有个大概印象，用到的时候现查。我的
Chrome浏览器里，
php手册和
ChatGPT这两个网页标签是一直开着的。那天我工作了一会儿后，放空脑袋在
php手册里随便点击函数的时候，看到了bcscale下面一条七年前的小提示。突然，我就像被点亮了一盏明灯一样。这里有个前置情况：数据表使用decimal(8,2)，单位是元，保留两位小数。一开始项目里与金额相关的数据只精确到分，也就是两位小数，后来来的同事在处理数据时保留四位小数，最后存入表中时又更新为两位小数。按照我的推测，报表这个定时任务运行的时候，使用了bcscale()函数设置了两位小数的精度。由于整个逻辑又复杂又冗长，运行效率很低，需要运行较长时间。在这个过程中，又有其他定时任务运行了，并且也使用了bcscale()函数设置了四位小数的精度，结果就影响到了报表的定时任务。
