-
我在 Python 里用内置的 round 给一批金额做四舍五入本以为这是小学就会的常识级操作不可能出错,结果对账时总额老是差那么几分钱单个数也对不上,我把 round(0.5) 打出来看到的竟是 0 而不是 1 当场就懵了,排查很久才搞懂 Python3 的 round 用的根本不是我以为的四舍五入而是四舍六入五成双的银行家舍入的深度复盘
我做一个涉及金额计算的功能、要把一堆金额四舍五入到整数或两位小数,想都没想就用了 Python 内置 round——这不就是四舍五入嘛。可上线后对账出问题:把一批数各自 round 再求和、总额和财务按四舍五入算的预期值总差那么几分钱平不了;挑几个 .5 结尾的单独试更头皮发麻——round(0.5)=0 不是 1、round(2.5)=2 不是 3、但 round(1.5)=2、round(3.…- 0
- 0
-
我用 float 累加订单金额,对账时发现总额差了几分钱、还有一笔订单因为金额判等永远不成立而卡住:一次 Python 浮点数精度坑、钱绝不能用 float 表示的深度复盘
我们的订单系统金额计算图省事全用了 Python 的 float,结果炸出两个 bug:财务月底对账,系统总金额和逐笔加起来的正确值差了几分钱、死活对不平;还有一笔订单明明金额一分不差,if paid_amount == order_amount 这个判付清的判断却永远是 False、订单一直卡在未付清。在解释器里敲 0.1 + 0.2 才看明白:它不等于 0.3、而是 0.30000000000…- 0
- 0
-
一段用 float 累加金额的 Python 代码,在几万笔订单后对账差了几分钱,让我栽进了二进制浮点精度的坑:一次用错数值类型的深度复盘
财务追了三天:Python 日终对账总额和逐笔加起来的应有总额每天差几分钱,飘忽不定,逻辑却怎么看都没错。直到在终端敲下 0.1 + 0.2 得到 0.30000000000000004,才惊觉根因是用 float 累加金额——float 是二进制浮点,0.1 这类十进制小数在二进制里无限循环、只能存近似值,每笔金额带微小误差,几万笔累加飘出几分钱,且 0.1+0.2==0.3 为 False。本…- 0
- 0
-
我用 Python 的 float 累加金额做对账,几万笔加下来总额和数据库就是差了几分钱,我对着浮点数精度排查了大半天的复盘
写了个对账脚本,把几万笔交易金额用 Python float 累加和数据库总额核对,逻辑简单到不能再简单,结果死活对不上——我算的总额和数据库总是差那么几分钱。反复检查数据没漏没重、加法没写错,可几万笔加完就是差 0.03 这种诡异小数。一度怀疑数据库、怀疑数据精度,最后敲了行 0.1 + 0.2 看到输出 0.30000000000000004 才恍然大悟:问题出在 float 本身,它根本存不…- 3
- 0
-
对账总差那么一分钱:我在 Python 里用 float 算钱,被浮点数的 0.1 + 0.2 != 0.3 坑到怀疑人生的复盘
系统每天对账,隔三差五就冒出一笔"差几分钱"的账,我查遍业务逻辑也找不出原因。直到在解释器里敲下 0.1 + 0.2,得到 0.30000000000000004,才如遭雷击——真凶是我用 float 算钱。十进制小数 0.1 在二进制里是无限循环,float 只能存近似值,成千上万笔累加,微小误差就汇成了那笔幽灵般的一分钱。这篇从浮点数为何算不准讲起,梳理 Decimal、整…- 0
- 0
-
购物车总价差一分钱:JS 浮点数精度避坑复盘
有个电商页面的购物车前端用 JavaScript 实时计算总价:单价乘数量再累加显示给用户,功能简单到我都懒得多测就上线了。可没过几天客服转来一个诡异投诉:有用户结算时前端显示的总价和后端最终算出的金额差了一分钱。一分钱不多,可金额对不上在交易系统里就是天大的事,用户截图质问、财务对账报警。我把那个用户的购物车数据捞出来在控制台手动一算当场就笑不出来了:0.1 + 0.2 在 JavaScript…- 0
- 0
-
金额计算完全指南:从一次"对账差了一分钱、查了三天"看懂浮点数陷阱与 Decimal 实践
2022 年我做一个带账务的系统要记每一笔钱的进出每天还要对账。存金额算金额这件事我压根没多想。第一版我做得很省事金额不就是个数字用 float 存加加减减不就完了。余额是个 float 每来一笔流水就加一下要展示就直接打出来。本地开发时真不错我自己造几笔流水测加出来的数对账的数看着都对几行代码搞定。我心里很踏实金额嘛不就是个数字。可等这个系统真正上线记了成千上万笔真实流水一串问题冒了出来。第一种…- 2
- 0
Decimal
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×