前阵子帮朋友看一个对账脚本，跑出来怎么都对不上，差了几分钱，maddening。翻了半天才发现，他图省事把金额直接用了 double。你看 0.1 加 0.2，在 IEEE 754 底下根本不是 0.3，而是 0.30000000000000004，肉眼看着一样，放进等号两边比较就是不等。嗯

更要命的是这种误差会滚雪球。他那个脚本里有循环累加，每笔利息再算一遍，几十万笔跑下来偏差就肉眼可见了。金融场景里"少一分多一分"是绝对不能忍的，可偏偏这种地方最容易埋雷，还埋得毫无声息。
其实
后来改成了整数，金额一律以"分"为单位走 long，显示的时候再除一百。需要更精细的，比如带汇率换算的，就上 decimal 那种任意精度的库，别拿浮点硬顶。说穿了特别简单，踩过一次才知道疼。你们有没有也在这上面栽过的？

我之前也撞见过这坑，对账对到半夜真的frustrating。long走分最稳，记下了

你最后提的decimal，我顺着补一句：它严格说不算"任意精度"，更接近"可调精度"。像Python的Decimal默认28位有效数字，精度和舍入模式都能设，但一旦设了上限，算着算着超出去照样丢。真要任意精度，得用分数（有理数）或者bigint那类。金融实务里把位数设够一般就稳了，但概念上别混为一谈，免得哪天拿它去跑超长计算链翻车。
其实
早年我也被double坑过一次，对账差了几块钱，查到半夜。后来一律老老实实long存分。你提到的乘法顺序那个坑我多嘴一句：本金乘利率时若先乘后除，中间值可能撞long上限，先除又损精度，得看量级取舍。

你们几十万笔纯累加，long稳得很，就当提个醒。

楼主这个坑我前两年也踩过，对账差三分钱查到半夜，frustrant 得很。
严格来说
想补一个点：decimal 库真不是"任意精度"就完事了。BigDecimal 的精度靠 context 设定，除不尽时（比如汇率换算里 1 比 3.749 这种）默认直接抛异常，不会自动替你舍入。所以它只是把隐形误差变成你要自己拍板的四舍五入规则，误差没消失，只是从暗处挪到明处了。具体还是得想清楚每笔按什么规则舍到哪一位。

这个坑我也撞过。整数分对付存储和等值比较确实是治本，但想补一句：一旦涉及利息、汇率这种乘除，long 照样要你先拍板 rounding 规则。比如 100 分乘 1.035 得 103.5 分，收 103 还是 104，round half up 还是 banker’s rounding，不定死就又是一笔糊涂账。decimal 库也不是免死金牌——Python 的 decimal 做除法若不显式设 precision 和 rounding mode，会直接抛 inexact；Java 的 BigDecimal.divide 遇到除不尽同样抛异常，不是默默给个近似值。float 真正坑人的，是它算出来的数和你写的字面量根本不是同一个，差在看不见的最后几位，你却拿 == 去比。你们项目里 rounding 规则落进文档了，还是靠口头约定？

补一个容易被忽略的点：你说 decimal 是"任意精度"，这话对一半。BigDecimal 确实能精确存下 0.1，但只要一涉及除法或汇率换算，不显式指定 rounding mode 它就直接抛 ArithmeticException。所以换类型只是把隐患从"看不见的误差"变成了"必须显式做决定的舍入策略"——截断、四舍五入还是银行家舍入，几十万笔跑下来差异照样不小。

我前阵子看人脚本就栽在这：Decimal 用着用着因为某处没设 scale，对账时在某些分支悄悄挂了。

前两年我也跟着折腾过类似的东西，当时也是图省事直接上 double，结果跟楼主朋友一个下场 (￣▽￣)

不过有一点想补一句：改成 long 走"分"确实稳，但主要解决的是"存"和"加"。其实一旦碰到按笔算利息、按比例分摊这种会出现"半分钱"的中间步骤，long 就歇菜了，必须落到 decimal。而 decimal 也不是帖子里说的那种"任意精度"——Python 的 decimal 默认 28 位有效数字，Java 的 BigDecimal 也得你手动定 scale 和 rounding mode。说白了它把"怎么舍入"这件事摆到台面上让你自己负责，而不是真的无限精确。

顺带一提，decimal 默认的舍入多半是 round-half

这坑真不少见。我前阵子帮人弄个小记账的玩意儿，也是图省事上了浮动点数，对账永远差几毛，查得头大。换整数分之后世界清净了，显示再除一百，土是土了点但顶用。不过 long 也不是万灵药，循环里乘个利率出来的零头，舍入规则不定好照样兜不住。

记农户台账时也遇过这茬，几分钱怎么都对不上，后来用整数分才踏实。

补充一个容易被略过的点：decimal / BigDecimal 标着"任意精度"，但一遇到除法就还得自己定规矩。按汇率换算、算百分比利息，只要除不尽，Java 的 BigDecimal 不指定 rounding mode 会直接抛 ArithmeticException，Python 的 Decimal 则默默按上下文默认的 ROUND_HALF_EVEN 舍入。其实所以"换 decimal 就稳了"其实还差半步：真正要拍板的是舍入口径，而且得和金融那边对齐，round half up 还是 banker’s rounding，差一个点位对账照样翻车。

你那个 long 存"分"的思路我完全赞成，但中间运算得留神截断。比如算利息走 amount * rate，rate 先转整数再乘、还是先乘后缩放，顺序错了尾巴就被整数除法吃干净；汇率那段若先除后乘，几百万笔累积下来的偏差反而可能比 double 还邪门。

说到底，金额链路上的缩放、舍入、取整，每一步都该当作显式决策，别交给语言默认行为。你改成分为单位是正路，顺手把负数、零利率、除不尽这些边界列个表测一遍就好。你们一般谁定这套舍入规则？

想起一桩旧事。前两年一朋友拉我看他们小店的记账工具，也是差几分钱怎么都对不上，翻出来是他把单价乘数量的结果塞进了float接着累加。他当时还嘟囔"电脑算的还能有错"，其实错不在机器，在用法。

楼主说的拿"分"当单位走long，这是最稳的招，越土越好使。我想补一嘴的是，别以为换成整数就彻底太平了。真遇到要分摊、按比例拆一笔钱，整除分不匀的尾差照样冒出来。一百块按3:3:4分给三家，以分为单位算，前两家各33，最后一家34，多那一分归谁，得在写的时候就定死规则，不然跑久了还是对不上。

decimal那类库也有人在舍入模式上栽。默认四舍五入还是银行家舍入，差之毫厘。见过有人以为换上decimal就高枕无忧，月底和银行对账还是歪了，根子还在舍入规则没拉齐。
坦白讲
这类毛病最烦人的就是它从不报错，安安静静把错结果递给你。你们那脚本后来是只动了存储层，还是连比较逻辑一并重写了？