浮点数误差常见原因解析

你是否曾惊讶于 Python 中 `0.1 + 0.2 != 0.3`？这并非语言缺陷，而是所有遵循 IEEE 754 标准的编程语言共有的二进制浮点数本质限制——十进制小数如 0.1 在二进制中无限循环，只能被近似存储，导致微小误差在计算、比较或循环中悄然累积甚至放大；本文深入剖析误差根源，揭示何时必须改用 `decimal.Decimal`（如金融场景），如何用 `math.isclose()` 安全比较，以及哪些操作（如大数相减、累加顺序、float 做循环变量）会意外引爆误差，帮你避开那些“看似无害却让程序深夜崩溃”的精度陷阱。

为什么 0.1 + 0.2 != 0.3 是正常的，不是 bug

这是二进制浮点数表示的固有限制，不是 Python 特有，所有遵循 IEEE 754 标准的语言（JavaScript、C、Java）都这样。十进制小数 0.1 在二进制中是无限循环小数（类似十进制里 1/3 = 0.333...），只能被近似存储。

Python 默认用 64 位双精度浮点数，有效数字约 15–17 位十进制数字。一旦参与计算，误差会累积，尤其在连续加减、比较或作为循环边界时容易暴露。

• 0.1 + 0.2 实际结果是 0.30000000000000004，打印时 Python 会自动舍入显示为 0.3，但底层值没变
• 用 repr(0.1 + 0.2) 能看到真实表示：'0.30000000000000004'
• 直接用 == 比较两个浮点计算结果，几乎总是错的

什么时候该用 decimal.Decimal 替代 float

当你需要精确十进制算术，比如金融计算、会计校验、配置阈值校准——这些场景不能容忍“多出 0.000000000000004 元”这种误差。

decimal.Decimal 把数字存为十进制整数 + 指数（例如 Decimal('0.1') 存的是 (1, -1)），完全规避二进制表示问题，但代价是速度慢、内存占用高、不支持 math 库大部分函数。

• 必须用字符串初始化：Decimal('0.1')，写成 Decimal(0.1) 就白搭——因为 0.1 传进去前已经是近似值了
• 混合运算要小心：Decimal('0.1') + 0.2 会把 0.2 转成近似 Decimal，建议全程用字符串构造
• 除法默认保留无限精度，可能触发 InvalidOperation，需显式设 getcontext().prec = 28

怎么安全地比较两个 float 是否“相等”

用 math.isclose()，它基于相对误差 + 绝对误差双判断，比手写 abs(a - b) 更鲁棒。

关键参数：rel_tol 控制相对容差（默认 1e-09），abs_tol 控制绝对容差（默认 0.0）。当比较接近零的数时，abs_tol 必须显式设值，否则 isclose(1e-20, 0.0) 会返回 False。

• 推荐写法：math.isclose(a, b, abs_tol=1e-10)，尤其涉及接近零的值
• 避免用 numpy.allclose() 做标量比较——它专为数组设计，行为略有不同且额外依赖 numpy
• 单元测试里别写 assert a == b，统一换成 assert math.isclose(a, b, abs_tol=1e-10)

哪些操作会让浮点误差突然变大

不是所有运算都“温和”。有些看似简单的行为，会把微小误差放大成明显偏差，尤其在科学计算或数值算法中。

• 大数减大数：1e16 + 1.0 - 1e16 结果是 0.0，不是 1.0——因为 1e16 和 1e16 + 1 在 float 中无法区分
• 累加顺序影响结果：sum([1e10, 1.0, -1e10]) 得 0.0，但 sum([1.0, 1e10, -1e10]) 得 1.0；用 math.fsum() 可修复（它用部分和算法）
• 用 float 当循环变量：for x in [0.0, 0.1, 0.2, ..., 1.0] 极易漏掉或重复某个值；改用 range() 整数驱动，再除以步长

误差本身不可怕，可怕的是把它当成精确值去分支、索引或序列化。真正难处理的，永远是那些你忘了它不精确的时刻。

以上就是《浮点数误差常见原因解析》的详细内容，更多关于的资料请关注golang学习网公众号！