之前帮公司弄对账脚本，图省事直接拿 double 把几百笔订单金额累加，再跟系统总额比。逻辑看着没毛病，结果跑出来的差额是几分钱、几毛钱，时有时无，复现都复现不出来，差点被财务追着问。

根子就在 IEEE754。0.1+0.2 在浮点里根本不等于 0.3，二进制表示不了太多十进制小数，误差每累加一笔就偷偷攒一点。单笔看不出来，量一大就冒头，而且不是每次都冒，纯看脸。拿浮点直接 == 或者 != 比金额，基本是在给自己挖坑。

后来老老实实改成用整数分来存钱，或者上 decimal／定点数，比较的时候也丢个 epsilon 容差，不再裸比。一句话，钱这东西碰都别用浮点直接碰。我这种做外贸的，账对不上可不是闹着玩的，面包要紧。btw 现在凡是涉及钱的字段，一律整数处理，绝不手软。

你最后那句"纯看脸"得纠一下。IEEE754 的舍入是 deterministic 的，一点都不随机。复现不出来是因为你没把那几百笔的输入顺序和具体数值固定住——浮点每加一笔都按同一套规则丢低位，样本一换，哪几位翻车就跟着变，看着像抽签，其实随便抽一笔都能手算还原出来。
简单说
另一个点，比较时丢 epsilon 容差对钱属于治标。epsilon 是给物理量那种自带测量误差的场景用的。钱要的是 exact match，最稳还是整数分直接比相等，别拿容差去盖。decimal 没问题，但记住它只是把"分"这件事封装好了，除法和 round 的语义还得你自己定，不然照样翻车。

读着读着想起小时候数零钱，攥在手心里总觉得比记账本上多几枚，摊开一数又对不上。那种说不清的差额，跟你说的一个样，不是算错了，是它本来就在那儿，只是有时藏得住，有时藏不住。

你那句"纯看脸"真叫人心里一沉。最怕的就是这种看不见的偏倚，一点点攒着，平时温顺得像什么都没发生，冷不丁在你最信它的时候露一角。钱是这样，日子里的许多事大约也这样。

我后来但凡碰数字都先想清楚它到底是什么"单位"，哪怕只给自己记个账。整数分这招确实干净，像是把模糊的水沥干，剩下的颗颗都踏实。

epsilon 容差其实是治标，误差累积到一定程度照样越阈值。涉及钱还是整数分或 decimal 最稳，别拿浮点赌运气。

差几分钱还复现不出来最要命，闷头查到半夜不知道漏哪笔。整数分这招稳

想补充一点，就是帖子里那句"改成整数分或者 decimal，比较时丢个 epsilon 容差"——整数分/定点 和 epsilon 其实是两回事，叠在一起用反而有点拧巴。

epsilon 容差是给浮点准备的退路。当你被迫拿 double 存金额、又必须判断两笔"相等"时，因为 0.1+0.2 不等于 0.3，直接 == 会翻车，才退而求其次比个差值小于阈值。可一旦你真把金额存成了整数分（元乘 100 塞进 int64 之类），或者用了真正的十进制定点类型（decimal 内部是十进制编码，不是二进制浮点），每一笔都是精确值，误差从源头就不存在了。这时候还挂个 epsilon，等于给自己留了个口子：一个真实差了一分钱的对账错误，会被容差悄悄吞掉，财务查账时更摸不着头脑。

所以更干净的是二选一，别叠 buff：要么全程整数分加精确比较，要么只在极少数甩不掉浮点的场景才上 epsilon，而且阈值得按业务最小币种显式定，比如半分，而不是随手写个 1e-9。

另外"每累加一笔就偷偷攒一点"方向不是单向的。二进制舍入有时进有时舍，累计误差可能部分抵消，这也解释了你遇到的"时有时无、复现不出来"。double 有 53 位尾数，约 15–17 位十进制精度，小账期内误差通常极小，量一大或者撞上某些特定数值组合才露头。你们做外贸多一道汇率换算，那层的舍入点也得单独钉死，不然浮点坑填平了、汇兑那层又漏了。

0.1+0.2 不算出 0.3 这点最扎心，我以前也听人说过类似的坑。最怕的还是误差时有时无、复现不出来，财务一追问真是有嘴说不清。改整数分就踏实了，钱的事经不起半点侥幸。