前两天帮人看个对账对不上的 bug，翻半天最后揪出一行 if (a == b)。这行看着没毛病，其实是个埋了好久的坑。
0.1 加 0.2，IEEE 754 底下算出来不是 0.3，是 0.30000000000000004。根子在二进制没法精确表示多数十进制小数，0.1 本身在二进制里就是无限循环，存进内存那一刻就已是近似值。拿两个近似值做 ==，差一个最低位整条判断就翻车。
最烦的是它不挑时候发作。某些输入路径下乖乖相等，换批数据或者换台机器，浮点运算顺序一变结果就飘，复现都复现不出，线上随机抽风。循环累加、金额扣减、坐标判定这些场景尤其要命，bug 跟着数据随机冒头，排查的人头秃。
正经做法是容差比较：fabs(a - b) < eps，eps 按你的精度需求取。算钱这种关键量干脆别用浮点，整数分或定点数存，从根上绕开。这坑谁都得踩一回，踩过就长记性了。
这帖容差比较那段还差一句：eps 不能拍脑袋定。数量级一大，固定 eps 照样翻车，得用相对误差或按 ULP 比。我碰过的对账 bug 多半就栽在 eps 取得太随意。
替你捏把汗，这种藏得深的 bug 最磨人。翻半天代码最后栽在一行 == 上，换谁心里都堵得慌。
会好的
我前阵子也撞过一回，循环里累加几个小数，前几百次都妥妥的，某天突然对不上，盯着屏幕半天没想明白。后来才懂你讲的容差比较，fabs(a-b) < eps 这法子确实省心。
算钱那句我也认同，关键量还是整数分存最稳，从源头上就不给自个儿留坑。你这帖子写得明白，踩过的人看了都亲切。
帖子里"换台机器结果就飘"这句我补个细节。IEEE 754 本身是确定性的，同一条运算顺序在同一架构上结果完全一致。真正让跨机器漂移的是实现层：编译器开 -ffast-math、循环展开方式不同、或者 x86 有 FMA 别的 CPU 没有，乘加被合并成一步，舍入点一变最低位就偏。根子不是浮点"随机"，是运算顺序在不同环境下被悄悄改了。
容差比较再补一条：fabs(a-b) < eps 只在两侧量级接近时靠谱。坐标或物理量判定里数值可能从 1e
eps 取多少最磨人。单用 fabs(a
自己之前写个记账小脚本也栽过，差几分钱对到怀疑人生，复现都复现不出来最折磨人
我年轻那会儿也犯过类似的轴。那时候帮朋友弄个小记账的东西，sum 一列数死活和手工对不上，我愣是盯着那行等号看了半天才反应过来，两个数长得一样，内存里却隔着几个最低位。后来才算慢慢明白，看着"相等"这种事，很多时候只是你没撞上它不等的那一回。
楼主说的容差比较是正解，我就补一点自己后来吃过的亏。eps 不是写完 fabs(a-b) < 1e-9 就完事了。我见过有人拿同一个 eps 去比金额、又去比坐标，金额那边量纲小还好，等到比一些跨度大的量，比如从零点零零几到上百万的玩意儿，固定一个阈值要么太松要么太紧。稳妥点的做法是绝对误差叠相对误差，大致是 fabs(a-b) <= max(eps_abs, eps_rel * max(fabs(a), fabs(b)))，具体数值看你那摊事儿的精度要求。
还有个藏得深的，就是你那句"换台机器就飘"。根子大多在浮点运算顺序，所以复现这种 bug，光喂同样的数据不够，连编译选项、优化开关都得锁一致。我见过有人开了 fast-math 把精度直接干没，本地怎么都复现不出，最后才查清。
这种坑踩过一回真就长记性了。我现在但凡碰到要比较、要累加的地方，手都会先停一下，想想这数到底精不精确。你们项目里是统一封个比较函数，还是各写各的？
0.1+0.2 那个 0.30000000000000004 每次看见都觉得它在跟我装，太欠了。之前我也被循环累加坑过，查半天才知道不是我手抖是浮点天生不老实
连数字都没法真正相等，这事实念出来竟有几分温柔的残忍。我们总把「相等」当作天经地义，可二进制在把 0.1 写进内存的那一瞬，就已经悄悄改写了承诺。你写它不挑时候发作，像生活里那些埋着的刺，平日相安无事，某个寻常时刻忽然扎你一下，还找不出道理。
想起李商隐那句「此情可待成追忆，只是当时已惘然」，倒不是矫情。那种「从根上就回不去」的怅惘，和计算里的近似值竟是同一种滋味。人总想抓住确定的、永不变的东西，世界却偏用最低位那一点偏差来提醒你，一切皆是近似。其实
fabs(a
循环累加那块补一句：fabs(a-b) < eps 用绝对容差，数值跨度大时会失灵，大数差 1e