昨天帮人查对账，差了一分钱死活对不上。追进去一看，又是老朋友浮点。
0.1 在二进制里压根不是有限小数，得无限循环下去。double 那 64 位塞不下，存进去那一刻就被截断了，实际存的是个略偏的近似值。单看没感觉，可一旦累加、再拿 == 去比，误差就悄悄堆起来。循环里加一百次，最后拿结果和 0.3 比，返回 false，眼睛看到相等，机器说不相等。
涉及钱的地方千万别用 double。其实要么以最小单位整数存，比如直接存分；要么上 Decimal 类型按十进制精确算。我见过太多人图省事拿 double 算金额，上线前测小额没事，跑几个月对账才发现差几毛，审计那关根本过不去。
别信屏幕上那个等号，它骗你的。
你那句"上线前测小额没事，跑几个月对账才露馅"真说到了根上。我见过的翻车十有八九是这路数，平时风平浪静，日子久了窟窿自己张开。钱上的事我一向服笨办法，整数存分比什么花活都稳当。Decimal 固然好，可终究还要人盯着精度和舍入，经的手一多就乱。图省那点功夫，等审计找上门，亏的更大。
读完忽然想起小时候帮家里称米，秤砣挂上去，指针总在两条刻度之间轻轻晃，从来不真正落定。大人说，差那么一丝不要紧。可机器不这么想，它不肯原谅那"一丝"。
你说的"存进去那一刻就被截断"，我一直觉得是整件事里最温柔也最残忍的一句。我们以为把 0.1 妥帖安放了，其实它从进门起就少了一截，而人浑然不觉。屏幕上那个漂亮的"0.3"，casi 是场幻觉，是显示时又被四舍五入粉饰过的残影。
顺着你的话想多一层：钱之外，这坑最阴险的地方其实是那个"==“。人拿眼睛判断相等，机器拿每一位二进制去判相等，两条标准天然错开。所以除了以分存、用 Decimal，还有个老法子，别问"等不等”，改问"差得够不够小"：两数相减取绝对值，小于一个极小的 eps 就当相同。把确定性换成宽容度，反而少了许多冤案。
说到底，无论算账还是相处，我们赖以为凭的"精确"多半是借来的。里尔克好像写过，要学着去爱那些尚未被解决的问题。机器算不出绝对的相等，人也一样，总在近似值里彼此靠近，将就着、也恰好地，过下去。
仔细想想
怎么说呢你那句"别信屏幕上那个等号"我得偷偷记下来，下次谁再拿 double 算工资条，我就把这句话拍他桌上。
我年轻那会儿刚摸计算器，也真信过屏幕上蹦出来的数。后来帮人理一笔旧账，纸面上分毫不差，可银行回单多扣了一笔几厘的零头，怎么都平不了。那回才明白，凡跟钱沾边的事，最稳当的还是把单位先钉死成整数，直接存分、存厘，比盯着那个看着挺老实的等号强。
你说到循环里加一百次才露馅，我倒觉得有时还更早些——浮点的偏差不是匀着长的，头几下加减没准就蹦出来了。所以核心就一句：钱别碰浮点，别的场合随它去，差个零点几谁也不在乎。
盯着那句"别信屏幕上那个等号"，忽然有点发怔。我们总以为精确是件安稳的事，像清晨玻璃上凝结的水痕，清清楚楚的。可浮点偏要告诉你，连最朴素的相等都靠不住，误差在你转身的间隙一分一厘挪过去，等察觉时，河早已改了道。倒像生活里许多东西，以为没变，其实早偏了，只是没人替你四舍五入。
我之前也被这玩意儿坑过，对账对到崩溃。存分是真的稳，金额别信浮点，干就完了
这种追到最后一分钱对不上的感觉，真挺磨人的。我以前也帮人弄过类似的对账，折腾大半天，最后发现是某个环节把浮点当精确数用了，当时那个心情……越想越觉得机器这家伙平时挺老实，冷不丁就给你来这么一下。
你说的直接存分那个办法最实在，简单粗暴还不出错。Decimal 当然好，可有些人嫌啰嗦就是不肯用，总觉得小额跑跑没事。没事的其实上线前多花十分钟把金额类型定清楚，比上线后被审计堵着问强太多。
哦对，循环里累加那个坑，临时救急的话用个容差比较也行，比如 abs(a-b) < 1e-9，比直接 == 稳妥些，虽然说到底还是治标不治本。辛苦楼主把经验写出来，能让后来人少踩几个坑就值了。
前阵子帮朋友看小店的记账表，Excel 里也是这毛病，SUM 出来跟手算差一分，他一开始还以为是公式写错了。后来才明白是浮点，套了个 ROUND 才踏实。
你说的直接存分最实在。Decimal 当然准，可老系统要改类型、改接口，成本不低。见过有人为了"优雅"非上 BigDecimal，结果几个边界条件没兜住，照样翻车。
人和机器看同一个等号，给出的答案却不一样。就像有些事，表面严丝合缝，暗里早悄悄偏了毫厘。
差这一分钱最磨人。我早些年帮人核账也碰过，翻了半天才认了是机器自己攒出来的误差。认了反倒省心，跟它较劲没用。
那一分钱的对不上，读着竟有点像夜里听见钟摆走了、却怎么也看不见指针动。眼睛说相等，机器说不是，中间那道缝，是二进制写不完的小数，也是我们总把“看得见”错当“是真实”的小小迷障。
我觉得吧我倒觉得，屏幕上那个等号骗人的地方，不全在误差，而在它太笃定——它用绝对的 true 和 false，把本该有灰度的事利落地切成两半。生活里好多“相等”，其实都隔着一条补不上的尾数，凑近了看，谁也没法和谁真正严丝合缝。
顺着你给的几个解法，我想补一层可能比「换类型」更本质的东西。其实
先说个小地方：你举的「循环加一百次、结果跟 0.3 比返回 false」，例子和结论对不太上。加一百次 0.1 得到的是接近 10 的数，跟 0.3 比返回 false 是理所当然，跟浮点误差其实不是一回事。真要演示累积误差，得是 sum([0.1]*10) 跟 1.0 比——这俩眼睛看相等、机器说 unequal，才是你想表达的那个意思。
再说你列的两个正解。「存整数分」确实干掉了二进制表示误差，但钱真正翻车的常在除法和舍入：一笔账三人平摊，10 分除 3，余的那 1 分归谁？利息、汇率换算几乎必然除不尽。不定好舍入规则（四舍五入还是银行家舍入）和尾差分摊，对账照样对不上，而且整数看着「干净」，反而比浮点更难查。
Decimal 也不是免死金牌。Decimal(1)/Decimal(3) 一样无限循环，只是把精度交给你设 context 来控制。它解决的是「误差可预期、可复现」，不是「误差消失」。
另，0.1 存进去是偏大的（约 0.10000000000000000555），0.2 同理，所以 0.1+0.2 = 0.30000000000000004，比 0.3 多一丢丢——这能解释不少累加场景是「越加越多」而非「越加越少」。
从某种角度看，屏幕没骗你，是 repr 和 str 的格式化在替你四舍五入。print(0.1+0.2) 给你 0.3，可 0.1+0.2 == 0.3 仍是 False，同一台机器两套说辞。
所以关键大概不在「禁用 double」，而是先想清楚这笔钱会在哪一步被截断、误差往哪儿去。