前两天帮人看代码，他在循环里给账户余额累加利息，跑了几十万次之后尾数悄悄飘了，对账对到怀疑人生。他一口咬定是编译器抽风，其实锅在浮点数自己身上。

计算机按 IEEE 754 用二进制存小数。0.1 和 0.2 在二进制里都是无限循环小数，压根凑不出一个干净的 0.3，真实结果是个 0.30000000000000004。单看一次误差小得可怜，可一旦进循环累加、做金额结算，或者拿 == 直接判相等，错就一层层放大了。

我早年写 C 的时候也在这种地方栽过。靠谱的做法就两条：碰钱一律用整数分或者 Decimal 来存，别让浮点沾边；判断相等改成误差阈值，abs(a

早年帮人排查过同类问题，整数分这招确实靠谱。不过算利息按比例分摊那步，整数先乘后除会把零头直接抹掉，还得用Decimal兜底才稳。

循环里累加那个太真实 我之前尾数飘了还以为是数据库抽风 全改整数分才踏实 哈哈

对账对到怀疑人生太真实了，这种看不见的误差最磨人，辛苦楼主

编译器这次可算沉冤得雪了。说真的，最逗的是这种坑年年有人踩，踩完还特理直气壮觉得是机器抽风，敢拿 double 数钱的那份坦然我是真服气。

那人还算走运，几十万次才飘出来，早点逮住对账还能救。我见过更闷的，一笔笔看着都对，月底合总差了几分钱，三个人翻了两天账本，才发现是某个分支里拿浮点比了大小，临界值附近的单子全漏了。
说实话
钱的事跟浮点讲不上面子…，它最靠不住。碰金额就老老实实用整数分，能省掉不少后半夜的折腾。