Python浮点数精度问题全解析：从0.1+0.2到Decimal解决方案

你有没有遇到过这种情况：明明是个再简单不过的加法，Python 算出来却是 0.30000000000000004；或者两个浮点数看起来一模一样，== 判断却返回 False。我第一次被这个问题坑到，是在做数据清洗时对一个金额列做累计求和，算到最后一位多了几分钱，怎么对都对不上。后来一圈排查下来，问题的根源根本不在业务逻辑，而在浮点数精度。

这篇文章我把浮点数精度这件事从头到尾讲透：先说清楚计算机里浮点数到底怎么存的，再说哪些场景最容易踩雷，最后给出一套完整的、分场景的解决方案。无论你是刚学 Python 的新手，还是常年写数据分析、量化交易策略、后端接口的开发者，只要代码里出现过 float，这篇文章都值得花十分钟读完。

1. 浮点数精度问题的本质：计算机里到底发生了什么

1.1 0.1 这个数，在二进制里根本不存在

很多人一听“浮点数精度”就觉得是 Python 的 bug，其实这口锅 Python 不背。问题的根源在“进制转换”这件事上。

人类日常用的是十进制，但计算机底层只有 0 和 1。十进制小数转换成二进制小数，靠的是“乘 2 取整”的规则：把小数部分不断乘以 2，取整数位作为二进制位，直到小数部分为 0。比如 0.5 转二进制，乘以 2 得到 1.0，取整数位 1，结果是 0.1，干净利落。但 0.1 转二进制呢？0.1 × 2 = 0.2，取 0；0.2 × 2 = 0.4，取 0；0.4 × 2 = 0.8，取 0；0.8 × 2 = 1.6，取 1……这个计算会一直循环下去，永远达不到小数部分为 0。换句话说，0.1 在二进制里是一个无限循环小数，就像 1/3 在十进制里是 0.3333... 一样。

但计算机的存储空间是有限的。Python 里的 float 默认采用 IEEE 754 双精度 64 位格式：1 位符号位、11 位指数位、52 位尾数位。52 位尾数只能存下有限个二进制位，存不下的部分就只能舍入。所以你看到的 0.1，其实是一个“非常接近 0.1 的二进制近似值”，而不是精确的 0.1。

可以自己动手验证一下：

python复制>>> format(0.1, '.20f')
'0.10000000000000000555'

看到没有，第 17 位小数开始就“露馅”了。这就是浮点数精度的本质：绝大部分十进制小数，在二进制里根本没法精确表示，只能存一个近似值。

1.2 误差不是单次运算的问题，而是会累积的

理解了 0.1 本身是近似值之后，0.1 + 0.2 != 0.3 就很好解释了：两个近似值相加，结果也是一个近似值，而这个近似值碰巧不等于 0.3 的近似值。

python复制>>> 0.1 + 0.2
0.30000000000000004
>>> 0.1 + 0.2 == 0.3
False

单次运算的误差可能只有 5e-17 这种量级，看起来无伤大雅。但误差可怕的地方在于它会累积。你在一个循环里做一万次加法，每次误差都往同一个方向偏，最后的结果可能就差出好几分钱；你在科学计算里做矩阵迭代，误差经过指数级放大，整个结果可能直接发散。

还有一个非常经典的坑，是“大数吃小数”：

python复制>>> 1e16 + 1
10000000000000000.0
>>> 1e16 + 1 == 1e16
True

1e16 在二进制下需要一个很大的整数部分，留给小数部分的尾数位就不够了，+1 这种级别的变化根本“挤”不进去。这就好比一个只能装 16 位数字的行李箱，你已经装了 16 位整数，再想塞进一个“1”，就得把后面一位挤掉。

2. 哪些场景最容易让精度问题“爆雷”

2.1 三类高危特征，中一条就要警惕

不是所有浮点数运算都会出问题，但下面三个特征只要中了一个，你就得提高警惕。

第一是相等比较。只要代码里出现 == 来比较两个浮点数，基本就是在埋雷。0.1 + 0.2 == 0.3 只是一道入门题，真正可怕的是在业务代码里判断“金额是否等于退款金额”“传感器读数是否等于阈值”，这类判断在某个临界点上突然返回 False，排查起来极其痛苦。

第二是累加聚合。大量小数连续相加，误差一步步累积。比如一段循环里不断 total += item_price，跑了几千次之后，total 跟数据库里的精确值对不上是很常见的事。Python 的 sum() 对浮点数的处理也谈不上精确，只是做得比手写循环稍微好一点而已。

第三是连续乘除运算。每一次乘除法都会产生新的舍入误差，而且乘除法会把误差成倍放大。尤其是折扣、税率、汇率这类涉及小数乘法的业务，误差会顺着计算链路层层传递。

2.2 真实项目里的“重灾区”

结合我自己的经历，下面几个场景是浮点数精度问题的高发区：

• 金融与支付系统：金额、折扣、税率、退款，每一笔都必须分毫不差。这里用的 float 一旦出错，轻则账不平，重则资金对不上，属于绝对红线。
• 数据清洗与统计分析：对一列浮点数求均值、方差、求和，误差累积后可能影响分析结论。特别是用 pandas 做 groupby 聚合，列里有大量小数时，聚合结果的最后几位经常出现脏数据。
• 量化交易策略：策略信号往往基于历史价格的计算，比如均线、涨跌幅、收益率。浮点误差可能导致开平仓条件在临界点反复触发或漏触发，实盘环境里这种“差一点点”非常致命。
• 接口对接与数据序列化：后端计算出的金额通过 JSON 传给前端，前端再展示或二次计算，任何一个环节的近似都会让最终显示和实际值对不上。
• 科学计算与数值模拟：迭代越深，误差越大，甚至出现结果发散、震荡这类现象。

判断一个场景危不危险，可以问自己三个问题：这个结果要不要参与精确比较？运算次数多不多？误差能不能被业务容忍？只要前两个答案是“是”，第三个是“否”，就必须换方案。

3. 系统化解决方案：分场景选型，别一把梭

3.1 方案总览与选型思路

很多人一遇到精度问题就想着“用 Decimal 就完事了”，这种一刀切的做法其实也不对。Decimal 有它的性能代价和使用限制，有的场景用整数行，有的场景用高精度方案，有的场景只需要在比较时做一点处理。先看一张选型表：

选型的原则很简单：关键业务用精确类型，普通场景用“补丁”，性能敏感用整数化。

3.2 Decimal：最常用的精确计算方案

decimal 模块是 Python 做精确计算的首选。它默认使用 28 位有效数字，可以通过 getcontext().prec 调整：

python复制from decimal import Decimal, getcontext

getcontext().prec = 50
a = Decimal('1') / Decimal('3')
print(a)  # 0.33333333333333333333333333333333333333333333333333

但 Decimal 有个隐藏比较深的坑，很多人第一天就踩：Decimal(0.1) 和 Decimal('0.1') 完全是两个东西。

python复制>>> Decimal(0.1)
Decimal('0.1000000000000000055511151231257827021181583404541015625')
>>> Decimal('0.1')
Decimal('0.1')

Decimal(0.1) 接收的是一个 float，所以它先拿到的是那个“不精确的二进制近似值”，再转成 Decimal 也没用，误差已经传导进来了。正确做法永远是传字符串：Decimal('0.1')。这一点我在代码评审里强调过无数次，还是有人不断踩坑。

另外，Decimal 和 float 混用会直接报错：

python复制>>> Decimal('0.1') + 0.2
TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'

这个设计其实是故意为之，目的是防止误差“污染”精确计算。你需要在入口处就把所有参与运算的值统一转成 Decimal，比如 Decimal(str(price))，或者干脆从一开始就把数据源处理成字符串。

性能上 Decimal 比 float 慢一个数量级以上，但对于普通业务系统里的订单金额、报表计算，这点差距完全感知不到。真正的高频数值循环（比如图像处理、矩阵运算）不适合用 Decimal，那属于 numpy 的地盘。

3.3 fractions：有理数场景的另一种精确方案

如果计算过程只涉及四则运算、不涉及无理数，fractions 模块也是个不错的选择。它用“分子/分母”的形式精确表示任何有理数，比如 1/3 就是真正的 1/3，不会变成 0.3333...：

python复制from fractions import Fraction

a = Fraction(1, 3)
b = Fraction(1, 6)
print(a + b)  # 1/2

这个方案适合教学演示、数学工具类代码，以及一些需要保留分数形式的场景。但它有两个明显限制：第一，sqrt、sin、log 这些运算会把结果变成无理数，Fraction 根本接不住；第二，运算全是精确有理数运算，性能比 float 慢得多，不适合大规模数据。所以我的判断是：能用 Decimal 解决的业务问题，不需要绕道 Fraction；但如果是纯数学场景，Fraction 的“所见即所得”非常有价值。

3.4 不想改类型？三个“补丁”必须掌握

很多老项目里 float 已经满天飞，全部改成 Decimal 成本太高，这时候可以用几个“补丁方案”把问题控制在可接受范围内。

第一个补丁是 math.isclose()，用来替代浮点数相等比较：

python复制import math

math.isclose(0.1 + 0.2, 0.3)
# True
math.isclose(0.1 + 0.2, 0.3, rel_tol=1e-9, abs_tol=1e-12)
# True

rel_tol 是相对容差，abs_tol 是绝对容差。我的建议是：默认使用 rel_tol=1e-9，涉及接近零的值时补一个 abs_tol，避免两个数都是 0 附近的极小数时误判。

第二个补丁是 math.fsum()，替代普通的 sum() 做高精度求和：

python复制>>> sum([0.1] * 10)
0.9999999999999999
>>> math.fsum([0.1] * 10)
1.0

fsum 使用了 Neumaier 求和算法，比朴素求和慢一些，但能显著减少累积误差。凡是需要把一长串浮点数加起来的场景，我都建议无脑换成 fsum。实测在处理几万条浮点数据时，fsum 的结果往往比 sum 精确好几个数量级。

第三个补丁是“显示归显示，计算归计算”。round() 和 format() 只用来格式化输出，绝不能用它们的返回值去参与后续判断：

python复制>>> round(2.675, 2)
2.67

很多人以为 round(2.675, 2) 应该是 2.67 还是 2.68 的问题，本质也是二进制近似值导致的。2.675 存进计算机后实际是 2.6749999999999998...，四舍五入自然就变成了 2.67。所以我的做法是：金额计算全程用 Decimal，只在最终展示时做一次 format(value, '.2f')；如果项目里已经全是 float，那就接受这个显示误差，不要试图用 round 去“修正”。

3.5 数据分析与科学计算场景的精度对策

再说说 numpy 和 pandas 这两个高频场景。numpy 默认使用 float64，和 Python 原生 float 一样的精度问题，只是它在底层做了向量化，性能极高。在 numpy 里大批量使用 Decimal 对象，性能会急剧下降，因为 Decimal 本质上是 Python 对象，无法享受 SIMD 加速。所以数据分析场景里更实用的方案是“整数化”：把金额乘以 100 转成“分”，用整数运算，展示时再除以 100。

pandas 的坑相对隐蔽：groupby().agg('sum')、mean() 这些聚合操作都会产生累积误差。我的解决思路是：凡是金额类字段，要么统一用 Decimal 对象列，要么在入库时就按最小单位存成整数，聚合完毕后再转回十进制展示。我见过不少同事对着 pandas 显示的一长串小数位数发呆，原因其实就是浮点误差被聚合放大了，这时候用 df.round(2) 只能治标，把数据源改成整数才是治本。

还有一个容易被忽略的场景：数据可视化。有人在画图时发现横坐标刻度标签挤成一团，以为是精度问题，其实那纯粹是刻度数量设置的问题，需要用 plt.xticks(rotation=45) 或者调整 MaxNLocator 的参数，别把锅甩给浮点数。

4. 实战案例：一个订单金额计算的完整改造

4.1 先用 float 写一版，看看问题在哪

假设现在要算一个订单金额：商品单价 19.99 元，买 3 件，打 85 折，再按折后价收 6% 的税。用 float 写起来很顺，但结果经不起推敲：

python复制price = 19.99
quantity = 3
discount = 0.85
tax_rate = 0.06

subtotal = price * quantity
discounted = subtotal * discount
tax = discounted * tax_rate
total = discounted + tax

print(subtotal)   # 59.96999999999999
print(discounted) # 50.97449999999999
print(tax)        # 3.0584699999999993
print(total)      # 54.03296999999999

这一串数字打印出来，光是看着就让人头疼。你把它传给前端，前端显示 54.03；再拿这个值去跟财务系统对账，对方系统里可能算出的是 54.04。谁对谁错？谁都没错，只是两边浮点舍入的路径不一样。

4.2 用 Decimal 重写，看清每一步

Decimal 版本要记住一个铁律：所有数字都从字符串进来。

python复制from decimal import Decimal, getcontext, ROUND_HALF_UP

# 明确有效数字精度
getcontext().prec = 10

price = Decimal('19.99')
quantity = Decimal('3')
discount = Decimal('0.85')
tax_rate = Decimal('0.06')

subtotal = price * quantity
discounted = subtotal * discount
tax = discounted * tax_rate
total = discounted + tax

print(subtotal)   # 59.97
print(discounted) # 50.97450
print(tax)        # 3.058470
print(total)      # 54.032970

每一步都清晰准确，没有任何多余的近似尾巴。需要注意两点：第一，getcontext().prec = 10 表示整个上下文里 Decimal 运算最多保留 10 位有效数字，不是小数点后 10 位；第二，财务计算里四舍五入规则也很重要，Decimal 默认是 ROUND_HALF_EVEN（银行家舍入），如果想用常见的“四舍五入”，要显式指定：

python复制total = total.quantize(Decimal('0.01'), rounding=ROUND_HALF_UP)
print(total)  # 54.03

quantize() 才是 Decimal 里真正的“四舍五入到指定小数位”，不要用内置的 round() 去处理 Decimal，规则和表现都不够可控。

4.3 性能到底差多少？用数据说话

有人担心 Decimal 太慢，我用 timeit 跑了简单测试：100 万次加法，float 大约耗时 0.05 秒，Decimal 大约耗时 0.6 秒，差了 10 倍以上。但注意，这是 100 万次的量级。普通订单计算一天能跑 100 万次吗？绝大多数系统做不到。真正的性能瓶颈在数据库和网络，CPU 上这零点几秒的差异几乎可以忽略。

我的结论是：**业务金额计算，无脑用 Decimal；科学计算、数值仿真、图像处理这类重计算任务，继续用 float，通过整数化和算法设计来控制误差。**不要为了一个订单金额去跟性能较劲，也不要为了跑个矩阵去逐元素用 Decimal，分场景选型才是系统化的解法。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

5.2 排查精度的三板斧

遇到浮点数表现“不正常”时，第一件事不是改代码，而是先看清这个数的真实面目。我常用的三招：

第一招，用 repr() 或 format(x, '.20f') 查看完整值：

python复制>>> repr(0.1)
'0.1'
>>> format(0.1, '.20f')
'0.10000000000000000555'

注意 repr(0.1) 显示的是 '0.1'，因为 Python 的 repr 会显示“最短的、能唯一区分这个浮点数的字符串”，这是一种刻意的友好设计，但它也掩盖了真实值，容易让人误以为 float 是精确的。

第二招，用 .hex() 看二进制表示：

python复制>>> (0.1).hex()
'0x1.999999999999ap-4'

这一招能直接看到浮点数在内存里的二进制结构，适合深度排查和对比两个浮点数的差异来源。

第三招，用 as_integer_ratio() 看有理数比值：

python复制>>> (0.1).as_integer_ratio()
(3602879701896397, 36028797018963968)

这行输出说明 0.1 在 Python 眼里实际上是 3602879701896397 / 36028797018963968，一个并不等于 1/10 的分数。看到这个，你对“近似值”三个字会有非常直观的体感。

5.3 我踩过的几个坑，希望你别再踩

第一个坑是修改 getcontext().prec 后忘了恢复。getcontext() 返回的是当前线程的上下文，修改会影响当前线程里所有后续 Decimal 运算。有一次我在项目里设置了 prec = 30，结果后续所有模块的 Decimal 计算都跟着变了，排查了很久才发现是上下文被污染。现在我的习惯是：需要临时改精度时，用 localcontext() 把它包起来：

python复制from decimal import localcontext

with localcontext() as ctx:
    ctx.prec = 30
    result = Decimal('1') / Decimal('7')

第二个坑是在 JSON 接口里直接传 float 金额。前后端对接时，一个 54.03296999999999 直接就把前端的展示搞崩了。后来我们统一约定：金额类字段在接口层必须转成字符串，或者按最小单位传整数（比如 5403 表示 54.03 元），由展示层去格式化。这个约定救了很多次命。

第三个坑是把 Decimal 和 float 混着算。报错倒是小事，最怕是你在某个地方用了 float(decimal_result) 又塞回 float 计算链路，以为自己用了 Decimal 很安全，实际上精度在老早就被转没了。记住一个原则：Decimal 要用就用在完整链路上，不要中间切回 float。

第四个坑是可视化场景里的高精度“假问题”。有一次同事拿着 matplotlib 画出的图来找我，说横坐标标签都叠在一起，怀疑是浮点精度问题。我一看那数据范围从 0.0000001 到 0.0000007，处理坐标轴刻度才是关键。用 MaxNLocator 控制一下刻度数量、或者把坐标轴格式改成科学计数法，问题马上消失。很多看似精度问题的现象，本质是刻度和格式设置的问题，排查之前先分清类型，别一上来就动数据。

我在实际项目里踩过几轮坑之后，现在的代码评审标准已经非常明确：金额、税率、积分这类强规则字段，一律不准用 float 存储和传输；浮点数比较一律用 isclose；大规模累计一律用 fsum；需要在接口和前端之间传递精确数值时，要么字符串要么整数最小单位。这个标准执行下来之后，精度相关的线上问题几乎销声匿迹了。最后再分享一个小技巧：如果你不确定某个计算会不会有精度问题，最快的办法是直接把 format(结果, '.20f') 打印出来看一眼，一旦发现第 17 位往后不是干净的 0，那就说明浮点误差已经在这个计算里“路过”了，该往 Decimal 迁移就尽早迁。