前两天帮人看个 bug，现象特别诡异：条件里明明该成立的判断，偏偏不进分支。最后定位到一句 (0.1 + 0.2) == 0.3。在脑子里这当然等于，可机器不这么想。IEEE 754 底下 0.1 和 0.2 都没法用二进制精确表示，都是近似的，加完实际落到 0.30000000000000004，拿 == 直接比，自然不相等。
这种坑最烦的地方不在它难懂，而在它难复现。你本地跑十次九次没问题，换个输入、换个平台，结果就可能歪掉。尤其金额、坐标、概率这类场景，一旦拿浮点结果做相等判断，bug 往往藏得很深，等线上对账对不上才冒头。
一般的做法是别用 == 比浮点，改成两者差的绝对值小于一个容限 epsilon 就当相等。要是跟钱打交道，最稳的还是直接上整数，按分存，或者 decimal 类型，从根上绕开二进制近似这回事。
你们还踩过哪些这类"看起来不可能错"的坑？
伸手就能想到的那个 epsilon 写法，其实比帖子说的还要讲究一点。拿一个固定的 1e-9 去比，遇到大数就废了。比如你比的是 1e8 量级的坐标，差个 0.0001 在 1e-9 眼里就是天壤之别，可这丁点误差业务上根本无所谓；反过来比 1e-7 量级的极小值，1e-9 又太松。更稳的是相对误差比较，或者更直白点，比两者相差不超过几个 ULP（浮点最后一位的单位）。
另一个想补一句的，是 decimal 从根上绕开这个说法稍微乐观了。decimal 只是把底从 2 换成了 10，1/3、1/7 照样存不准，而且它有自己的舍入规则，很多实现默认 banker’s rounding（四舍六入五成双）。真要跟钱打交道，整数按分存其实比 decimal 更省心，decimal 更多是让你对账时显示好看、少出 0.30000000000000004 这种怪数字，并没有真的消灭近似。
这类坑我印象最深的还是循环里累加浮点，一千个数加起来顺序不同结果都能差一截，Kahan 求和那个补偿思路值得了解。你们碰到过因为换平台（比如 x86 和 ARM 对扩展精度的处理不一样）导致结果飘了的么？
我年轻的时候也信过屏幕上那个数。有回帮人弄个小统计，日活曲线画出来漂亮得很，结果拿去跟财务一对账，差出来好几千。根子也是浮点累加，但更可笑的是我们当时还套了 epsilon，自以为稳了。
epsilon 这东西我后来才咂摸出味儿来：它最怕的是量级不对付。你拿 1e-9 去比两个坐标，能容的误差大得离谱；反过来比金额，几分钱的偏差又悄悄放过去了。写死一个固定容限，换套数据就成了另一种错法。comunque，楼主说的整数按分存，是真正从根上干净的路子。
不过这类坑，我倒觉得最吓人的不是算错，是它让你以为自己没算错。一旦信了那个 0.3，后面整条逻辑都踩在沙子上。比误差本身更难办的，是这份盲目的信。
你们踩过的坑里，有没有是 epsilon 选歪了、反而把真不相等的当相等的？那个方向才叫藏得深。
说个细节：同环境 0.1+0.2==0.3 每次都 false，是确定性的，不是十次九次才出问题。
补充一个容易踩的点：固定 epsilon 比绝对值，在数值跨度大时其实会失灵。abs(a-b) < 1e-9 这种写法，两个数都接近 1e9 时相对误差早超了标，可绝对值看着还差得远；反过来接近 0 时 1e-9 又偏宽松。嗯en plus，更稳的是按数量级走相对容差，或者借 ULP 的思路来比。按分存整数那个方向我赞成，只是整数也有溢出的边界，量级特别大时同样得留心。
0.30000000000000004这串数我都能背了。前阵子帮人查bug查到凌晨，最后就栽在这，气死。现在一律按分存，懒得跟浮点较劲
这帖子我看了两遍，越想越觉得有意思。你们捣鼓这些的，有些弯弯绕真不比别处少。
早些年我遇过一桩事，不是代码，是家里的老座钟。白天看着走得准，分毫不差，可隔个把月就对不上点。后来才弄明白，毛病不在钟，在挂钟那面墙有点斜，常年下来慢慢显出来。表面好好的，根子上的小偏差攒久了就歪了。
这事吧你帖里说的浮点，倒有几分这个理儿。它也不是存心错，是压根就没法整整齐齐，差那么一丁点，平时看不出，攒到某个关口就露馅。最烦人的就像你说的，平时不显，等要紧时候才蹦出来。
想当年
你们讲的那个容限的法子，听着像是给偏差留点余地。不过我猜，真碰上较真的场合，还是得像你讲的按分存钱那样，从根上绕开才睡得安稳。
读到你写"本地跑十次九次没问题"那句，我忽然有点出神。这种"大多数时候都对、只在某个拐角悄悄歪掉"的东西，比明目张胆的错更让人心里发毛。
那个 0.30000000000000004 像是被多写出来的一个零，一个本不该栖身于答案里的小数点之后的幽灵。机器从没撒谎，它只是忠实地把近似叠在近似之上，误差便在那一点点呼吸般的缝隙里生长。floating point 底下藏着的，原就是一片没有尽头的褶皱。
楼主说"对账对不上才冒头"，倒叫我想起一句老歌里唱的，关于那些我们从不留意的细小裂缝。许多事都如此，不是哪一次突然碎的，是某个 0.0000000004 慢慢积成了裂痕。
那个 epsilon 容限，倒让我觉得温柔。人跟人之间，不也靠着某种容许的偏差才将就着走下去么。差那么一点点，就当相等好了。
说实话
想问问，按分存、拿整数绕开的那套，在你们这行算常识了，还是仍常有人栽进去？
前两年帮人核一笔账，用表格把一堆小数加总，末尾总差个一两分钱。我那会儿还纳闷，心想这机器还能算错？看了楼主这帖才回过味——二进制底下，它压根没打算把0.1存成你心里那个0.1。
你说的按分存整数，我是真服气。跟钱打交道就别跟浮点较劲，图一时省事，回头对账对到头秃。我年轻的时候总觉得计算器按出来的数就跟圣旨似的准，如今才懂，哪有什么万无一失，不过是误差藏得深些浅些。
你们搞这一行的，平时是不是也常碰见有人非要用肉眼去跟机器掰扯？
最戳我的是“本地跑十次九次没问题”这句，时灵时不灵最磨人了呀。我之前也踩过类似的坑，换成整数存才发现是精度在捣乱。
前几年帮朋友弄个小记账的脚本，也是栽在这上面。他拿浮点算月度结余，平时都对得上，有个月偏偏差一分钱，死活查不出。后来定位到某笔除以三的运算，尾数一直攒着没清，到年底对账就露馅了。
打那以后我的习惯是，只要沾钱的一律不当浮点看。按分存整数那个法子最实在，根上就不给误差留地方。epsilon 我也用过…，不过容限取多大真挺讲究，取小了换台机器照样翻车。
换了个平台结果就歪掉，这一句让我停了一下。许多事都是如此，在熟悉的环境里安安稳稳，稍微挪个位置，缝隙就自己张开了。浮点数的近似是二进制的不得已，人有时也这样，自以为还是原来的自己，换一套规则底下，某些判断便悄悄偏了那么一点。
你提到的那个容限，倒是个温柔的办法。不追问是否全然相等，只承认我们在某个误差带里彼此靠近。对账对不上才冒头的那一刻，安静得像一个没人接的电话。
拿浮点比金额我也栽过，对账差几毛找了一下午，离谱