为什么 0.1 + 0.2 ≠ 0.3 ，其实不是语言出bug了，是计算机存数字的“老规矩”导致的——咱们干程序的，谁没踩过这坑啊？，为啥0.1+0.2不等于0.3，以及这背后到底咋回事儿。

你肯定见过这情况：在Python、Java、JS里写0.1+0.2，结果出来是0.30000000000000004，跟0.3对不上。但别以为所有语言都这样——比如用“十进制存数”的库（像Python的decimal、Java的BigDecimal），或者专门算数学公式的语言（像Mathematica），就能算准。但大部分语言为了快，用了个叫IEEE 754的“浮点数标准”，这就绕不开这个坑。

计算机底层只认0和1，所以存数字时，整数好办（比如5就是101），但小数麻烦了——它用“二进制科学计数法”，跟十进制的1.23×10²类似，只不过底数是2。

但问题来了：很多十进制小数，转成二进制是“无限循环小数”，就像十进制的1/3是0.333...永远写不完一样。比如0.1：

你想把0.1转二进制？得这么算：

0.1×2=0.2 → 整数部分是0（记下来0）

0.2×2=0.4 → 整数部分0（记00）

0.4×2=0.8 → 整数部分0（记000）

0.8×2=1.6 → 整数部分1（记0001，剩下0.6）

0.6×2=1.2 → 整数部分1（记00011，剩下0.2）

0.2×2=0.4 → 哎？又回到0.4了！接下来就是00011循环……

所以0.1的二进制是0.0001100110011...（0011无限循环），根本写不完。0.2呢？就是0.1的二进制左移一位，也是无限循环；0.3同理，也是无限循环。

计算机内存就那么大，不可能存无限位。比如最常见的64位双精度浮点数（你现在用的电脑基本都是这个），尾数部分只有52位有效数字（加上隐含的1位，总共53位）。面对无限循环的二进制小数，它只能“四舍五入”截一段存起来——这就相当于把0.1存成了一个“大概齐”的数，不是真的0.1。

举个例子：0.1在64位浮点数里实际存的是0.10000000000000000555...（比你以为的0.1大了一丢丢）；0.2存的是0.2000000000000000111...（也比0.2大一点）。俩“大概齐”的数加起来，结果自然是0.30000000000000004，而不是精确的0.3。