这绝对不是意外——二进制浮点数的精度限制和不同计算路径的差异，很容易导致这种反直觉的结果，咱们一步步拆解你的问题：

1. 你的例子里为什么结果不等？ #

先看你给出的数值：num=146097.0，div=365.2425。数学上146097 ÷ 365.2425 = 400，但问题出在浮点数的表示精度上：

• 365.2425无法精确表示为二进制浮点数，它在内存中存储的实际值是一个略小于真实值的近似值（比如365.24249999999997868）。
• 当计算num//div时，Python（或底层CPU指令）的逻辑是找最大的整数n，使得n * div ≤ num。这里400 * div的结果是146096.99999999999，确实小于146097.0，所以num//div返回400.0。
• 而计算num/div时，浮点数除法的过程可能引入额外的舍入误差，导致最终结果是一个略小于400.0的值（比如399.9999999999999），这时math.floor()自然会返回399.0。

两种操作的计算路径不同：//直接基于乘法验证找最大整数，而math.floor()依赖除法的结果，误差的积累方向不同，就产生了差异。

2. 这类例子多吗？ #

不算特别常见，但也绝非罕见。它们通常出现在两个条件同时满足的场景：

• 除法的数学结果是一个整数；
• 除数或被除数是无法精确表示为二进制浮点数的十进制小数（比如分母不是2的幂的数：0.1、0.05、0.2425等）。

只要触发这两个条件，就有可能出现floor(num/div)和num//div结果不一致的情况。

3. 怎么避免这种问题？ #

如果你的业务场景需要精确的十进制计算（比如财务、历法相关的计算，就像你的例子看起来和闰年天数有关），建议使用Python的decimal模块，它可以按照十进制规则精确处理小数，避免二进制浮点数的精度陷阱。比如：

from decimal import Decimal, getcontext

# 设置足够的精度
getcontext().prec = 20
num = Decimal('146097.0')
div = Decimal('365.2425')
result_1 = (num / div).to_integral_value(rounding='ROUND_FLOOR')
result_2 = num // div
print(result_1 == result_2)  # 输出True

内容的提问来源于stack exchange，提问作者Gershom Maes