1. 从一个让人怀疑人生的等式说起如果你在浏览器的控制台里敲下0.1 0.2按下回车屏幕上会稳稳当当地显示0.30000000000000004。第一次看到这个结果的人反应基本分三种第一种是觉得电脑坏了第二种是觉得浏览器有 bug第三种是怀疑自己这么多年数学白学了。我当年属于第一种加第三种甚至还专门换了一台机器去验证结果当然是一模一样的“打脸”。这个现象不是某个语言特有的毛病JavaScript、Python、Java、C、Go 里都能复现只要它们遵循同一套浮点数标准。换句话说这不是谁写错了代码而是计算机表示小数的方式决定的。标题里那句“你别耍我”其实说出了很多人的心声明明数学上 0.1 加 0.2 就是 0.3凭什么到了电脑里就变了味这篇内容就是要把这件事从头到尾讲清楚。我会从二进制表示这个根子上讲起把浮点数的存储结构、精度丢失的原因、为什么偏偏是 0.1 和 0.2 出问题、以及实际开发中怎么规避这类坑一层一层拆开。适合所有写过代码、被浮点数坑过、或者单纯好奇“电脑到底怎么存小数”的人看。哪怕你数学基础一般只要跟着思路走也能把这件事彻底搞明白。先说结论免得你带着疑问往下读0.1 和 0.2 在二进制里都是无限循环小数计算机只能用有限位数去近似近似之后再相加误差就暴露出来了。这不是 bug是精度取舍的必然结果。理解了这一点后面所有的现象都顺理成章。2. 浮点数到底是怎么存进计算机的2.1 为什么整数没事小数就出问题要理解浮点数的坑得先明白计算机的“母语”是二进制。整数在二进制里表示起来很干净比如 5 就是10110 就是1010每个整数都能用有限位精确表示。但小数就不一样了二进制的小数位权是 1/2、1/4、1/8、1/16 这样往下走的能精确表示的小数必须是这些分数之和。举个直观的例子十进制的 0.5 在二进制里是0.1因为 0.5 正好等于 1/2干净利落。0.25 是0.010.125 是0.001这些都没问题。但 0.1 呢它等于 1/10而 10 不是 2 的幂所以 0.1 在二进制里没法用有限位表示只能写成无限循环的形式。这就像十进制里 1/3 0.3333... 永远写不完一样二进制里的 0.1 也是写不完的。提示判断一个十进制小数能否被二进制精确表示有个简单办法——看它化成最简分数后分母是不是只含因子 2。分母是 2、4、8、16 这类能精确表示分母含 5、10、3 这类就不行。2.2 IEEE 754 标准浮点数的“身份证”现代计算机普遍采用IEEE 754标准来存储浮点数这是理解一切浮点数行为的钥匙。以最常见的双精度浮点数64 位为例它把 64 个比特位分成三段组成部分位数作用符号位 Sign1 位0 表示正数1 表示负数指数位 Exponent11 位决定数值的量级大小尾数位 Mantissa52 位决定数值的精度细节这个结构和科学计数法是一个思路。比如十进制的 1234 可以写成 1.234 × 10³二进制的浮点数也类似写成 1.xxxx × 2ⁿ 的形式。符号位管正负指数位管那个 n尾数位管 1 后面的 xxxx 部分。关键在于尾数位只有 52 位。这意味着无论多长的小数塞进这 52 位之后超出的部分就得被截断或舍入。0.1 的二进制展开是无限循环的52 位根本装不下只能存一个近似值。这就是精度丢失的源头。2.3 0.1 的二进制展开长什么样我们实际算一下 0.1 转成二进制的过程用“乘 2 取整”的经典方法0.1 × 2 0.2整数部分 00.2 × 2 0.4整数部分 00.4 × 2 0.8整数部分 00.8 × 2 1.6整数部分 10.6 × 2 1.2整数部分 10.2 × 2 0.4整数部分 0到这里你会发现0.2 又回来了接下来就是 0.4、0.8、1.6、1.2、0.4 这样无限循环下去。所以 0.1 的二进制是0.000110011001100110011...其中0011这一段无限重复。计算机只能截取前面 52 位存起来后面全丢掉。0.2 也是同样的命运它的二进制是0.0011001100110011...同样是无限循环。两个都存不准的数相加结果自然就偏了。这不是计算机算错了而是它一开始拿到的就是两个“近似值”。3. 误差是怎么一步步累积出来的3.1 从存储到相加的完整链路很多人以为误差是相加那一刻产生的其实不是。误差在存储阶段就已经埋下了。0.1 存进去的时候实际存的不是 0.1而是一个非常接近 0.1 的数大约是 0.1000000000000000055511151231257827021181583404541015625。0.2 同理存的是一个略大于 0.2 的近似值。当这两个近似值相加时误差就叠加了。更麻烦的是相加的结果还要再经过一次舍入才能塞回 52 位的尾数里。这一来一回最终得到的0.30000000000000004就是误差累积的产物。你可以把它理解成用两把刻度不准的尺子量东西量出来的和自然也不准。3.2 为什么偏偏是 0.30000000000000004这个尾巴不是随便冒出来的它是舍入规则作用的结果。IEEE 754 默认采用“就近舍入偶数优先”的规则也就是结果落在两个可表示值中间时选尾数末位为偶数的那一个。0.1 和 0.2 的近似值相加后真实结果落在两个可表示浮点数之间舍入之后就变成了0.30000000000000004。有意思的是如果你在控制台里直接输入0.3它显示的就是0.3看起来很正常。但这不代表 0.3 被精确存储了它同样是个近似值只不过它的近似值在打印时被格式化成了0.3而已。所以0.1 0.2 0.3返回false而0.1 0.2打印出来是0.30000000000000004两件事本质是同一个原因。3.3 一个容易踩的认知误区不少人觉得“既然 0.1 存不准那我用 0.5、0.25 这种总行了吧”。确实这些数能精确表示但问题在于只要参与运算的任意一个数存不准结果就可能不准。比如0.1 0.50.5 是准的但 0.1 不准结果照样有误差。所以规避浮点数问题的关键不是挑“好数”而是换一套表示方法。注意不要用直接比较两个浮点数是否相等这是新手最容易踩的坑。哪怕两个数看起来一样底层存储也可能差一个极小的量。4. 实际开发中怎么处理这类精度问题4.1 场景判断什么时候可以忽略什么时候必须处理不是所有涉及小数的场景都需要较真。如果你只是做页面展示、画个图表、算个大概比例那点误差根本看不出来直接用浮点数完全没问题。但有几类场景必须严肃对待金额计算一分钱的误差在财务系统里就是事故绝对不能含糊。科学计算误差会在迭代中放大几次运算下来可能面目全非。精确比较判断两个计算结果是否相等时直接比较必然翻车。累加统计大量小数累加误差会越滚越大。我个人的经验是只要涉及钱、涉及“相等判断”、涉及大量累加就必须换方案。其他情况可以睁一只眼闭一只眼别为了洁癖把代码搞得复杂无比。4.2 方案一整数化运算最朴素也最可靠的办法是把小数放大成整数来算。比如金额以“分”为单位1.23 元存成 123 分全程用整数运算最后再除回去。整数在二进制里是精确的只要不溢出结果就绝对准确。这个方案的好处是简单、快、不依赖任何库。缺点是得自己管好单位换算而且遇到除法要小心比如 10 分除以 3 是除不尽的得提前想好舍入策略。适合金额、数量这类单位明确的场景。4.3 方案二使用定点数或高精度库如果场景复杂整数化不好处理那就上专门的库。不同语言都有成熟的方案语言常用方案特点JavaScriptdecimal.js、big.js纯 JS 实现API 友好Pythondecimal 模块标准库自带可设精度JavaBigDecimal精度可控适合金融Gomath/big标准库功能全这些库内部用十进制或任意精度来表示数字绕开了二进制浮点数的先天缺陷。代价是性能比原生浮点数慢内存占用也高所以别滥用只在真正需要的地方用。4.4 方案三设定误差容忍度做比较如果只是要判断两个浮点数“差不多相等”可以引入一个极小的阈值。比如判断Math.abs(a - b) 1e-9只要差值小于这个阈值就认为相等。这个阈值怎么定取决于你的业务精度要求一般取 1e-6 到 1e-10 之间。这个办法适合比较场景但不适合累加场景因为误差还是会累积。而且阈值选大了会误判选小了又没效果需要根据实际数据调。我一般会把它封装成一个isEqual函数避免到处写魔法数字。5. 常见问题与排查实录5.1 为什么打印出来有时候正常有时候不正常这是最让人困惑的地方。0.1 0.2打印出0.30000000000000004但0.3打印就是0.3。原因在于打印时语言会做一层格式化把足够接近的数显示成“好看”的样子。0.3 的近似值和真实值差得太小格式化后就看不出差别而 0.1 0.2 的结果偏差稍大超过了格式化的“美化阈值”就原形毕露了。所以打印正常不代表存储精确这两件事要分开看。判断是否精确得看底层比特位或者用高精度库对比。5.2 常见问题速查表现象原因处理办法0.1 0.2 ≠ 0.3二进制无法精确表示用整数或高精度库累加结果偏差越来越大误差逐次累积改用整数累加两个数比较不相等底层存储有微小差异用阈值比较金额算出小数尾巴浮点数精度不足以分为单位存整数大数加小数没反应小数被大数“吃掉”调整运算顺序或换库5.3 几个我踩过的坑第一个坑是用浮点数存金额。早年做一个订单系统图省事直接用浮点数存价格结果对账时发现总差几分钱查了半天才发现是精度问题。后来全部改成以分为单位的整数问题立刻消失。这个教训让我记住了钱的事一律用整数。第二个坑是用比较坐标。做图形处理时判断两个点是否重合直接用等号比较结果明明看起来重合的点被判为不重合。后来改成算距离小于阈值才正常。图形计算里这种坑特别多因为坐标经过多次变换后误差会累积。第三个坑是以为换个语言就好了。有段时间我天真地以为 Python 的浮点数会比 JavaScript 准结果一试0.1 0.2照样是0.30000000000000004。因为大家都遵循 IEEE 754谁也逃不掉。想彻底解决只能换表示方法不能换语言。提示排查浮点数问题时先把参与运算的数用高精度方式打印出来看看实际存的是什么往往一眼就能看出问题所在。6. 把这件事彻底想明白的几个角度6.1 从“表示能力”看精度问题浮点数的本质是用有限的比特位去表示无限的实数。这中间必然有取舍就像用有限的像素去画一条平滑曲线放大看总有锯齿。理解了这个大前提就不会再纠结“为什么不能精确”而是接受“近似是常态精确是特例”。十进制里其实也有同样的问题。1/3 在十进制里是 0.3333...你写不完只能近似。二进制里的 0.1 就是类似的处境。所以这不是计算机的缺陷而是任何有限表示系统都会遇到的限制。6.2 从“误差传播”看运算顺序同样的几个数换个相加顺序结果可能不同。因为每次运算都会舍入舍入的时机不同误差累积的方式就不同。一般来说先加小数再加大的数误差会小一些因为小数相加时精度损失相对小。但这只是经验具体还得看数据分布。如果对精度要求极高可以用 Kahan 求和这类补偿算法它通过额外记录误差来修正结果能把累加误差降到很低。不过大多数业务场景用不上知道有这么个东西就行。6.3 从“标准设计”看取舍智慧IEEE 754 的设计其实很巧妙。它用相对误差而不是绝对误差来衡量精度这样无论数大数小相对精度都差不多。它还专门设计了表示无穷大、NaN 的方式处理了各种边界情况。我们今天遇到的“坑”其实是这套标准在通用性和精度之间做的平衡。想深一层如果当初设计成十进制浮点数0.1 就能精确表示了但整数运算会变慢硬件成本会上升。所以二进制浮点数是工程上的最优解代价就是某些十进制小数表示不准。理解了这层取舍心态就平和了。7. 写在最后的一点个人体会浮点数这个问题我前前后后给不同的人解释过很多次发现最有效的讲法不是一上来就讲 IEEE 754而是先让对方亲手在控制台里敲一遍0.1 0.2看到那个奇怪的结果产生“这怎么可能”的疑问再去讲原理接受度会高很多。带着问题学比干巴巴地听标准定义强得多。实际工作中我的原则很简单能用整数就用整数涉及钱必须用整数或高精度库比较浮点数一律用阈值其他场景别过度设计。浮点数的精度问题不是洪水猛兽知道它在哪里会咬人绕开就行。真正危险的是不知道它存在稀里糊涂地用了等到线上出问题才回头查那代价就大了。最后分享一个小习惯每次写涉及小数的逻辑我都会问自己一句“这里会不会有精度问题”。养成这个反射能省掉很多事后排查的功夫。这个习惯不值钱但很管用。