从CPython源码分析浮点数精度问题的根源：为何0.1+0.2不等于0.3？
目录导读
- 问题重现：一个让所有开发者困惑的经典现象
- 二进制浮点数的先天缺陷：IEEE 754标准如何埋下精度隐患
- CPython源码深度解析：从
floatobject.c看Python如何存储和计算浮点数 - 精度丢失的完整链路：进制转换 → 舍入 → 运算 → 显示
- 问答环节：针对常见疑虑的逐一解答
- 工程实践建议：如何在Python中安全处理浮点数
为什么0.1+0.2不等于0.3？
打开Python交互环境，输入1 + 0.2，你会得到30000000000000004，这不是Python的bug，而是几乎所有现代编程语言（包括C、Java、JavaScript）的共有特性，要理解原因，我们必须从CPython底层源码出发,追踪浮点数的生命周期。
二进制浮点数的先天缺陷：IEEE 754标准
CPython的浮点数实现完全遵循IEEE 754双精度浮点数标准（64位）,该标准将64位分为三部分：
- 1位符号位
- 11位指数位
- 52位尾数位（实际有效精度约53位）
核心问题：十进制小数要转换为二进制小数，例如1的二进制表示是无限循环小数：
0001100110011001100110011001100110011001100110011001101...而尾数只有53位，因此必须截断或舍入，这就产生了表示误差。
实例验证：在CPython中，1的实际存储值并不是精确的0.1,而是：
>>> 0.1.hex() '0x1.999999999999ap-4'
转换为十进制约为1000000000000000055511151231257827021181583404541015625
CPython源码深度解析：floatobject.c里的秘密
我们来看CPython 3.11源码中Objects/floatobject.c的关键部分：
1 浮点对象的创建
PyObject *
PyFloat_FromDouble(double fval)
{
PyFloatObject *op = free_list;
if (op != NULL) {
free_list = (PyFloatObject *) Py_TYPE(op);
// ... 复用对象
} else {
op = (PyFloatObject *) PyObject_MALLOC(sizeof(PyFloatObject));
if (!op) return PyErr_NoMemory();
}
/* Inline PyObject_NewFast */
Py_SET_TYPE(op, &PyFloat_Type);
op->ob_fval = fval; // 直接存储C语言的double值
_Py_NewReference((PyObject *)op);
return (PyObject *) op;
}
关键点：op->ob_fval = fval; 直接将C语言的double类型值存入对象，而C语言的double就是IEEE 754双精度，精度丢失在进入Python前已经发生。
2 加法运算的实现
float_add函数（位于floatobject.c第1489行）：
static PyObject *
float_add(PyObject *v, PyObject *w)
{
double a, b;
CONVERT_TO_DOUBLE(v, a);
CONVERT_TO_DOUBLE(w, b);
a = a + b; // 硬件级别的浮点加法
return PyFloat_FromDouble(a);
}
真相大白：两个有误差的double值相加，结果误差进一步累积。1和2的存储值相加后，得到30000000000000004。
3 打印时的再舍入
当你print(0.1+0.2)时，CPython调用float_repr函数，这个函数使用PyOS_double_to_string进行格式化，由于显示精度限制，最终只会显示到小数点后16位左右，但底层的二进制值永远无法精确等于0.3。
精度丢失的完整链路
十进制0.1 → 二进制无限循环 → IEEE 754截断/舍入 → 存储为近似值
十进制0.2 → 二进制无限循环 → IEEE 754截断/舍入 → 存储为近似值
两个近似值相加 → 二进制运算 → 结果再舍入 → 0.30000000000000004
↓
print时格式化再舍入 → 显示为0.30000000000000004问答环节（Q&A）
Q1: 为什么Python中的0 + 2.0没有精度问题？
A1: 因为整数1和2在二进制中是精确的（0=二进制0，0=二进制0），所以没有表示误差,精度问题只出现在无法用二进制有限表示的小数上。
Q2: Python的decimal模块能完全解决吗？
A2: decimal模块使用十进制运算，避免了进制转换误差，但代价是性能下降约10-100倍，且同样是有限精度（你可指定精度位数），对于财务计算，必须使用decimal。
Q3: 能否修改CPython源码让1+0.2等于0.3？
A3: 理论上可以改用十进制浮点运算（如decimal模块的实现），但这会破坏与C扩展的兼容性，且性能无法接受，Python设计者选择了遵循IEEE 754标准。
Q4: 为什么1的二进制是无限循环？
A4: 二进制整数部分(2的幂)表示规则与十进制不同，任何分母包含非2质因数（如3,5）的十进制小数,在二进制中都是无限循环的。
Q5: float.as_integer_ratio()能获取精确分数吗？
A5: 可以。(0.1).as_integer_ratio()返回(3602879701896397, 36028797018963968)，这实际上就是IEEE 754存储值的精确分数表示。
工程实践建议
| 场景 | 推荐方案 |
|---|---|
| 数值计算、科学计算 | 使用float，接受微小误差 |
| 财务、精确金额 | 使用decimal.Decimal |
| 比较两个浮点数 | 使用math.isclose(a, b, rel_tol=1e-9) |
| 避免累积误差 | 使用Fraction或Decimal |
| 检查浮点存储值 | 1.hex()查看二进制表示 |
经典代码陷阱：
# 错误做法 if 0.1 + 0.2 == 0.3: # 永远为False # 正确做法 import math if math.isclose(0.1 + 0.2, 0.3, rel_tol=1e-9):
通过从CPython源码角度的分析，我们看到浮点数精度问题的根源在于硬件层面的IEEE 754双精度表示法，以及十进制与二进制之间的进制转换误差，CPython只是忠实地将C语言的double运算暴露给Python开发者，理解这一点，你就能在开发中合理规避精度陷阱，并选择合适的工具（decimal、Fraction、math.isclose）来处理不同场景下的数值需求。