突然发现个问题，我们生活中的金融系统最多只有两位小数位，比如12.37，精确到分，但是当两位小数和非整数计算时也会得出三位小数啊，比如银行的日率，肯定会有计算得出三位小数或者更多小数位的，但是为什么我们只看得到两位小数的余额呢，多出的小数位不也是钱吗，被省略了吗，怎么省略的呢。感觉这个问题有点意思。
我的猜想：
实际上只要我们金融系统只是用两位小数，当产生超过两位小数时，后面的小数位都不要了，直接不要，而不是满五进一，如果进一，就造成多给用户钱了，哪怕是多给0.001元，这在整个系统中的损失也是巨大的，所以当出现两位以上的小数时，只能直接省去后面的小数位，哪怕是0.239也要省去0.009，这个0.009元的损失只能让用户承担。
比如银行的系统，支付宝，这些都是两位小数位的，我们一般余额字段都是使用decimal(10,2)，保留两位小数位，我突然想到这个问题，好纠结，不知道是不是我想的那样。
比如支付宝使用积分，购物券抵扣同时下多个订单时，那个抵扣的钱好像就是根据订单金额的比例拆分到每个订单下面去了，这样就出现小数了，但是那个小数也是两位，我没仔细注意过，不知道多个订单的抵扣加起来是不是等于下单时抵扣的钱。
如果是我想的那样，那这样我感觉很多时候我们肯定损失了好多钱了？我原本想多保留几位小数就可以解决这个问题，可是感觉可能还会有无穷的小数，还是不太可能，难道就只能让用户损失钱吗，哪怕只是那么一点点。
希望大神指点一下，搞得我好迷惑，目前项目中正遇到了这类问题。
谢谢！
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
其实并不是这样。我们电商财务系统在进行对账和对佣的时候通通算到了后6位。decimal(16, 6)在计算完之后才会四舍五入。一般最后四舍五入这一步是写在 协议里面的，最后一步我觉得应该属于协商的范畴吧。跟系统已经没啥关系了。
这块的资金问题还是得考虑业务需求的。按我以前的做法，是保存4位小数。根据不同的场景，进行取舍！但前台所有显示的金额都只显示2位，并向下取数
如以下场景：
余额提现、转出等
一般会向下取数，比如10.1234;那实际可提现金额为10.12。
分期相关
如银行额度总共为1000元，然后刚好买了一样东西，全花了，在操作分期。分3期；
按正常思维是1000/3=333.3333333;在四舍五入一下就成了333.33;等你三期都还完了，发现只还了999.99。这就坑了
一般做法是：
前2期按四舍五入计算。最后一期，按减法算：1000-333.33-333.33=333.34；
其他说明
根据不同业务，保留位数和取舍都不一样。如基金的净值。小数点的长度影响的资金量还是很大的。这块是越精准越好。具体需求跟产品沟通吧！
有个 银行家舍入 的方法，即：
舍去位的数值小于5时，直接舍去；
舍去位的数值大于等于6时，进位后舍去；
当舍去位的数值等于5时，分两种情况：5后面还有其他数字（非0），则进位后舍去；若5后面是0（即5是最后一位），则根据5前一位数的奇偶性来判断是否需要进位，奇数进位，偶数舍去。
按上述规则举例，假设我们要求数字要求精确到个位：
有个很好的例子来看出这种计算方式的优势：
2.55 + 3.45 = 6
如果我们要保留一位小数，去转换 2.55 和 3.45，则会变成这样：
2.6 + 3.5 = 6.1
很显然这样多了 0.1，那么按照我们的 “四舍六入五成双” 再来计算，2.55 实际上可以说是 2.550，我们要舍去的 5 的后面是 0，则根据前面一位的奇偶判断是否进位，很显然前面为奇数，则进位后为 2.6，对于 3.45，5 前面是偶数，则舍去，结果为 3.4，因此两者计算如下：
2.6 + 3.4 = 6