-
我在 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
-
我用 BigDecimal 的 equals 判断两个金额是否相等,2.0 和 2.00 明明都是两块钱,它却告诉我不相等:一次 BigDecimal.equals 把小数位也算进相等的深度复盘
我用 BigDecimal 表示金额(为了精确不用 float,这是对的),某处用 equals 判断两个金额是否相等。可线上偶发:两个数值上明明相等的金额(一个 2.0、一个 2.00,都是两块钱)equals 却返回 false,导致金额一致才放行的逻辑卡住。查清 BigDecimal.equals 才明白:它不只比数值,还比 scale(小数位数)——BigDecimal 内部用无标度值+s…- 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
-
我做金额计算,0.1 加 0.2 居然不等于 0.3,累加几笔钱后总额还对不上、比较相等也失败,我对着 JavaScript 浮点数无法精确表示小数这个坑排查了大半天的复盘
一个让我对计算机里的小数到底是什么彻底搞明白的坑,简单到难以置信却坑得怀疑人生:在 JavaScript(其实几乎所有语言)里 0.1+0.2 不是 0.3 而是 0.30000000000000004。涉及金额的功能,直接用浮点算:0.1+0.2===0.3 是 false、累加 10 次 0.1 得 0.9999999999999999、付 0.3 元(0.1+0.2)却被判付的不够。深究 I…- 4
- 0
-
我用 Python 的 float 累加金额做对账,几万笔加下来总额和数据库就是差了几分钱,我对着浮点数精度排查了大半天的复盘
写了个对账脚本,把几万笔交易金额用 Python float 累加和数据库总额核对,逻辑简单到不能再简单,结果死活对不上——我算的总额和数据库总是差那么几分钱。反复检查数据没漏没重、加法没写错,可几万笔加完就是差 0.03 这种诡异小数。一度怀疑数据库、怀疑数据精度,最后敲了行 0.1 + 0.2 看到输出 0.30000000000000004 才恍然大悟:问题出在 float 本身,它根本存不…- 3
- 0
-
我用 JavaScript 算钱,0.1 加 0.2 居然不等于 0.3,算出来的金额总是差那么一点点,我对着这串诡异的小数尾巴排查了大半天的深度复盘
我做金额计算,加加减减算总价,结果总带条诡异的小数尾巴:0.1+0.2 算出来是 0.30000000000000004、和 0.3 比较还返回 false,误差累积导致显示和对账总差一两分钱。我简直不敢信计算机连加法都算错。深究才懂这不是 JS 的 bug、而是几乎所有语言共有的浮点(IEEE 754)局限:计算机用二进制,而 0.1 换成二进制是无限循环小数(像十进制 1/3 除不尽),尾数位…- 0
- 0
-
对账总差那么一分钱:我在 Python 里用 float 算钱,被浮点数的 0.1 + 0.2 != 0.3 坑到怀疑人生的复盘
系统每天对账,隔三差五就冒出一笔"差几分钱"的账,我查遍业务逻辑也找不出原因。直到在解释器里敲下 0.1 + 0.2,得到 0.30000000000000004,才如遭雷击——真凶是我用 float 算钱。十进制小数 0.1 在二进制里是无限循环,float 只能存近似值,成千上万笔累加,微小误差就汇成了那笔幽灵般的一分钱。这篇从浮点数为何算不准讲起,梳理 Decimal、整…- 0
- 0
-
对账总差一分钱:JavaScript 浮点精度避坑复盘
这个 bug 是被财务同事追着问出来的。她说我们的对账系统总价偶尔会和实际差那么一两分钱,金额不大但财务的账差一分钱都不能容忍。我起初以为是某条数据错了,可翻来覆去查数据每一笔单价数量都对得上,加起来却就是会差一点点。我把计算过程一步步打印出来,终于看到了那个让无数程序员会心一笑又头皮发麻的经典场景:在控制台里敲下 0.1 + 0.2,得到的不是 0.3 而是一个诡异的 0.30000000000…- 11
- 0
-
购物车总价差一分钱:JS 浮点数精度避坑复盘
有个电商页面的购物车前端用 JavaScript 实时计算总价:单价乘数量再累加显示给用户,功能简单到我都懒得多测就上线了。可没过几天客服转来一个诡异投诉:有用户结算时前端显示的总价和后端最终算出的金额差了一分钱。一分钱不多,可金额对不上在交易系统里就是天大的事,用户截图质问、财务对账报警。我把那个用户的购物车数据捞出来在控制台手动一算当场就笑不出来了:0.1 + 0.2 在 JavaScript…- 0
- 0
-
金额计算完全指南:从一次"对账差了一分钱、查了三天"看懂浮点数陷阱与 Decimal 实践
2022 年我做一个带账务的系统要记每一笔钱的进出每天还要对账。存金额算金额这件事我压根没多想。第一版我做得很省事金额不就是个数字用 float 存加加减减不就完了。余额是个 float 每来一笔流水就加一下要展示就直接打出来。本地开发时真不错我自己造几笔流水测加出来的数对账的数看着都对几行代码搞定。我心里很踏实金额嘛不就是个数字。可等这个系统真正上线记了成千上万笔真实流水一串问题冒了出来。第一种…- 2
- 0
-
double 算钱算出误差:一笔分账对不上账的复盘
财务反馈营销活动结算时平台总账和商户分账总对不上,每天差几毛到几块。排查根因是一段分账代码用 double 在算钱。几天治理:认清浮点为何不精确、改用 BigDecimal 字符串构造、除法指定精度与舍入、比较用 compareTo、金额用 DECIMAL 或分 long 建模、加金额守恒断言。- 2
- 0
金额计算
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×