你有没有遇到过这种情况：在计算器里输入0.1 + 0.2，结果却不是0.3，而是0.30000000000000004？别以为是电脑出错了，这其实是浮点运算的“正常表现”。我们日常用的程序、电子表格、游戏画面渲染，背后都离不开浮点运算。搞清楚它的原理，能帮你理解为什么有些计算“看起来不对劲”。
什么是浮点数？
整数好办，1、2、3，计算机用二进制直接表示就行。但像3.14、0.0001这样的小数怎么办？这时候就得靠浮点数了。所谓“浮点”，意思是小数点的位置可以“浮动”，就像科学计数法里的写法：3.14 可以写成 3.14 × 10⁰，而0.00314可以写成3.14 × 10⁻³。计算机也用类似方式，把一个数拆成三部分：符号位、指数位和尾数位。
目前最通用的标准是IEEE 754，它规定了单精度（32位）和双精度（64位）浮点数的格式。比如一个64位的双精度浮点数，1位表示正负，11位表示指数，剩下52位表示尾数（也就是有效数字）。
为什么0.1 + 0.2 ≠ 0.3？
问题就出在“表示”上。我们习惯用十进制，但计算机用二进制。像0.1这样的数，在十进制里很简洁，但在二进制里却是无限循环小数：0.0001100110011…（不断重复）。计算机只能存有限位，所以只能近似存储，这就带来了精度损失。
当你输入0.1时，实际存的是一个非常接近0.1的二进制浮点数。0.2也一样。两个近似值相加，结果自然也只是一个接近0.3的数，而不是精确的0.3。
代码中的真实例子
下面这段JavaScript代码就很典型：
console.log(0.1 + 0.2); // 输出：0.30000000000000004
console.log(0.1 + 0.2 === 0.3); // 输出：false如果你在做金额计算时直接用浮点数，可能就会出问题。比如电商系统里算总价，几分钱的误差积累起来就可能对不上账。
怎么避免踩坑？
对于需要精确计算的场景，比如金融、会计软件，通常不会直接用浮点数。一种常见做法是把金额转换成分来计算，全部用整数操作。比如“12.34元”存成1234分，最后再除以100显示。
另一种方法是使用专门的高精度库，比如Python里的decimal模块，或者Java中的BigDecimal类，它们能按十进制规则进行精确运算，避免二进制浮点的误差。
当然，大多数情况下浮点误差影响不大。图形渲染、物理模拟、机器学习这些领域，数据本身就有噪声，轻微的舍入误差完全可以接受。关键是知道什么时候该小心，什么时候可以放心用。