Python3浮点数运算：0.1+0.2与0.3比较的正确选项疑问

底层机制前提 #

Python 中的float遵循 IEEE 754 双精度浮点数规范，所有无法转化为有限位二进制小数的十进制值，存储时都会带上固有误差，直接用==做精确等值判断本质上是不可靠的。

把题目里三个选项的实际运行结果逐一拆解： #

选项1：(var1 + var2) == var3 #

这个选项是完全错误的。
三个变量的实际存储值和字面十进制值存在固有偏差：

• var1=0.1的实际存储值约为0.10000000000000000555
• var2=0.2的实际存储值约为0.20000000000000001110
• 两者相加后的实际存储值约为0.30000000000000004440
• var3=0.3的实际存储值约为0.29999999999999998889

两个值存在明显的精度差，直接用==判断会稳定返回False。 #

选项2：round(var1,1) + round(var2, 1 ) == round(var3,1) #

这个选项在本题的给定场景下会返回True，也是题目给出的标准答案。
它的运行逻辑是：先对每一个原始操作数单独做1位小数的舍入，再执行加法、最后和舍入后的目标值做比较。在本题里，三个原始值本身就是1位小数的理想测试值，单独舍入后得到的就是精确的0.1、0.2、0.3，加法结果自然匹配。

但这个逻辑的适用边界非常窄，一旦跳出本题的理想化测试场景，就容易出现逻辑错误：
举个反例：如果var1=0.14、var2=0.24，我们需要判断两数之和是否等于0.38（精度到1位小数的目标值为0.4）。按照选项2的逻辑：
round(0.14,1) + round(0.24,1) = 0.1 + 0.2 = 0.3，和round(0.38,1)=0.4做比较，会错误返回False。
这个问题的本质是：提前对操作数单独舍入，会在计算过程中累积截断误差，导致结果不符合业务预期。 #

选项3：round(var1+ var2, 10) == round(var3, 10) #

这个选项在本题场景下同样会返回True，也是更符合通用浮点数比较逻辑的实现方式。
它的运行逻辑是：先完成原始浮点数的加法运算，不对操作数做提前截断，再对计算得到的结果、待比较的目标值，统一舍入到10位小数精度后做对比。

这种做法的优势是避免了提前截断带来的误差累积：不管原始操作数的固有误差有多大，都先完整走完计算流程，再根据统一的精度要求对最终结果做处理。在本题里，两个值的固有误差差大概在1e-17量级，远小于1e-10的舍入阈值，所以舍入后两个值完全相等，判断结果正确。 #

为什么题目把选项2设为标准答案 #

这道题的考察范围非常窄，核心只是想说明“直接用==比较浮点数是错的”，并没有覆盖浮点数比较的完整最佳实践。题目设计的是完全理想化的测试用例，没有考虑真实业务场景下的误差累积问题，所以刚好能让逻辑有缺陷的选项2跑出正确结果。

补充说明：不管是选项2还是选项3，本质都是用固定精度舍入做近似比较，生产环境中更稳妥的做法是判断两个值的绝对差是否在业务可接受的公差范围内（比如差小于1e-9就认为相等），比依赖round的截断逻辑更可靠。

内容的提问来源于stack exchange，提问作者Max Carberry