前几天帮人看一段求和代码，跑出来差了三块七毛钱，对方一口咬定是编译器坏了。简单说其实毛病出在0.1加0.2上——这俩在二进制里压根没法精确表示，算出来是0.30000000000000004，跟0.3比永远对不上。看着挺扯，但IEEE 754就是这么定的。

这种事最阴的地方在于它不报错。程序跑得飞快，结果一点一点偏，平时看不出来，等你在金融计息或者统计累加里叠了几百万次，误差就悄悄放大到你兜里少钱。新人最爱写 if (a == b) 去比浮点数，然后debug到怀疑人生。老老实实用容差，abs(a-b) < 1e-9 这种区间判断才靠谱。

说起来我早年做坐标变换也被这个坑过，矩阵乘着乘着模型就飘了。现在看到小数就条件反射先想它准不准。你们还有啥被浮点背刺过的经历，说出来让我心里平衡一下。

算账单那个太有共鸣了，我之前也差几毛钱…，折腾半天才发现是0.1加0.2的锅

容差那个写法我得补一刀：abs(a-b) < 1e-9 只对特定量级成立。要比的两个数要是上亿，1e-9 根本没意义——浮点在 1e9 附近的间距都远大于它；反过来两个数都贴着 0 做微小量运算，1e-9 又可能太宽，把本该区分的误差放过去了。稳一点用相对容差，或者 abs(a-b) <= max(abs(a), abs(b)) * eps 这种按量级缩放的判断，eps 取机器精度 2.22e-16 再乘个安全系数。

累加那个坑还能再挖一层。求和顺序真的影响结果，不是玄学——浮点加法不满足结合律，先加大数还是先加小数，末几位能差出去。几百万笔累加最好上 Kahan 求和（补偿求和），多保一个补偿项把每次舍掉的低位捡回来，误差能压好几个数量级。

钱的事其实别跟浮点较劲。人民币精确到分，直接 int64 存分，显示时再除 100，够用到天荒地老。非要小数就用 decimal 类型（Python decimal、Java BigDecimal，或者 IEEE 754 自己的 decimal64），十进制能精确表示 0.1 和 0.2，压根不会有 0.3000000004 这出，比调容差省心。

还有个容易上当的：很多语言打印 0.1 就是显示 0.1，但内存里其实是 0.1000000000000000055…，显示层帮你圆了，所以新人更会被骗。简单说调试别信眼睛，看 repr 或者 hex 表示才作数。

你那个矩阵连乘飘移，本质也是误差在每一步被放大再喂给下一步。光加容差救不了，得从算法层换数值稳定的写法。你当年最后是怎么收住的？

钱的事别拿容差糊弄，按分存整数才是最稳的。

补充一个容易被带偏的点：把 abs(a-b) < 1e-9 当成万能容差，这事值得商榷。

1e-9 本身没有来由，基本是抄来抄去的默认值。它的麻烦在于完全不考虑量级：两个上亿的数，浮点误差本身就能到 1e-8 量级，1e-9 反而严到会把"本该相等"的判成不等；而比较接近零的小数时，1e-9 又松得能把该区分的也放过去。容差得按数据的量级和允许的误差范围来定，不是扔一个常数包打天下。

其实再说你那个"差三块七毛"的例子，根子不在比得准不准，是用浮点存钱这件事本身就不对。金融计息、对账这类场景，正解是拿整数分或者 decimal 类型来算，浮点再怎么调容差都只是给近似结果打补丁。新人真正该记住的，可能不是"比较时留点余量"，而是"钱压根不该进 float"。

你矩阵乘着乘着飘掉那段，倒是典型的累积误差现场，这个我服。

差三块七毛钱就赖编译器，这锅甩得离谱。我早年也干过拿浮点凑整账的蠢事，零头飘出来能让人查到后半夜。你现在看见小数点还条件反射犯嘀咕吗？

三块七毛钱这个例子太扎心了，我之前帮人看账单也是差了几分钱死活对不上，最后发现是百分比四舍五入累积的锅，比浮点还阴，每一步单独看都"合理"。
可以可以
说真的浮点最气人的就是永远给你个正确答案隔壁的数，还一脸无辜不报错。现在正经算钱都有decimal类型，真搞金融就别拿float硬刚了，你说它错吧，它还真按规矩来的，气不气人。

容差那段值得商榷。abs(a

那个一口咬定编译器坏了的人，我太想扒一扒了。不是你是帮谁看的代码呀，同事还是外面接的活？三块七毛钱这数太具体，完全像从谁对账里硬抠出来的。我脑子里立刻开始脑补：是不是他自己逻辑写岔了，先甩锅给编译器，越查越心虚。

我早年写代码也被浮点背刺过，不是钱，是别的地方，后来看见小数就先打问号，跟楼主这反应一模一样。

哈哈哈容差那块顺嘴补一句，1e-9看场景，有人用1e-6有人更狠，新人照抄容易抄错量级。话说那个哥们后来认账没？纯八卦，我太想看他现在到底信不信IEEE 754了。

0.30000000000000004 这个数字，我盯着看了好久。它比 0.3 只多了一粒尘埃那么细的尾巴，可偏偏就是这一粒尘埃，能把人对机器的信任整个翻过来。

你说的"温柔一刀"，我特别有触动。它最狠的地方不在于算错，而在于从来不告诉你算错了。程序跑得比谁都勤快，结果却像春水暗涨，一寸一寸漫过堤岸，等你察觉时脚已经湿了。这世上许多事都是这样静默地偏出去的，不报警，不挣扎，只是慢慢地、体面地，离真相远了一点。

我想补一个角度：这种"用等于号去要一个它给不起的承诺"，好像也不只是浮点数的脾气。人有时候也拿 == 去量生活，非要某个瞬间和想象里严丝合缝才肯认，差那么一丝就觉得自己被骗了。其实好多"准"是容差里的准，是 abs(现实 - 期待) 小于一个能忍受的小数，才过得下去。

你那个坐标变换飘掉模型的经历，让我想起一句话，大意是说：所有精确都是借来的，利息就是遗忘。浮点不报错，是因为它太忠实于自己的规则；它只是太诚实，诚实到不肯替我们圆谎。
仔细想想
你们说的金融计息叠几百万次才显形，倒叫我想起滴水穿石。不是哪一滴特别用力，是时间悄悄站到了误差那边。

想起我大厂那会儿也撞过 对账差三块四毛 死活查不出 最后发现是这鬼玩意 当时真想砸键盘

你那个三块七毛钱的案子，根因其实不在比较方式，在选错了数据类型。涉及钱从一开始就不该进 float。最稳的做法是全程用整数（分，或者更小单位）去存去算，只在显示层除回去；真要带小数，用 decimal / BigDecimal 这类十进制定点类型。容差比较是兜底，不是给钱用的方案。

再说容差本身。abs(a-b) < 1e-9 只在两个数量级都在 1 附近时才靠谱。换成相对容差 abs(a-b) < 1e-9 * max(abs(a), abs(b)) 更扛造。反例很好举：两个 1e9 的数差 0.5，绝对值早超 1e-9，可你根本不在乎；两个 1e-12 的数差 1e-13，绝对值还远小于 1e-9，但相对已经偏了 10%。一个绝对阈值两头都失准。

第三类坑在累加方式，不在单点精度。一百万个数往一个 float 里顺序相加，误差不是随机抖，是系统性往一边飘——大数吃小数，后面的小项直接被舍进大数里。改用 Kahan 补偿求和或分治式的 pairwise sum，同样的数据误差能压低一两个数量级。矩阵乘飘也同理：不光是 float 精度问题，病态条件在放大误差，这锅不能全让 IEEE 754 背。

还有个常被忽略的点：0.1+0.2 那个 0.30000000000000004 不是算错了，是 0.1、0.2 各自存进内存时就被取了最近的、能表示的近似值…，相加只是把两份误差并到一块。Python 里 repr(0.1) 会四舍五入显示成 0.1，但它肚子里是 0x3fb999999999999a，那才是真相。其实

坐标变换那类我也撞过，模型转着转着就歪，后来把关键中间量用 double 重新归一化一遍才稳住