Python 金额计算：从 Decimal 创建到舍入与汇总

金额计算最容易出问题的地方，往往不是复杂公式，而是输入已经经过浮点转换、舍入规则没有写明，或者明细与总额采用了不同口径。Decimal 能用十进制表示数值，但它不会替我们决定业务规则。要得到可解释的结果，需要同时约定输入方式、精度、舍入模式和舍入时点。

先从字符串创建，不要先经过 float

Python 的 float 使用二进制浮点表示，很多十进制小数不能被有限位精确表示。因此，0.1 + 0.2 的结果可能与直觉不同。把这个浮点数再交给 Decimal，会保留它实际存储的近似值，不会自动恢复原来的十进制意图。

金额来自表单、CSV 或接口时，建议保留原始文本，例如使用 Decimal("19.90")。如果上游已经把金额转成浮点数，后续再转换只能处理现有值，无法找回已经丢失的信息。整数也能直接用于创建，例如 Decimal(100)；关键是避免无意间穿过浮点这一层。

一段可以直接运行的示例

下面代码只依赖 Python 标准库，展示创建、两种舍入规则和两种汇总方式：

from decimal import Decimal, ROUND_HALF_UP, ROUND_HALF_EVEN, localcontext

print("float_sum:", 0.1 + 0.2)
print("from_float:", Decimal(0.1))
print("decimal_sum:", Decimal("0.1") + Decimal("0.2"))

cent = Decimal("0.01")
for text in ("2.665", "-2.665"):
    value = Decimal(text)
    print(text, "HALF_UP:", value.quantize(cent, rounding=ROUND_HALF_UP),
          "HALF_EVEN:", value.quantize(cent, rounding=ROUND_HALF_EVEN))

with localcontext() as ctx:
    ctx.prec = 28
    amounts = [Decimal("0.335")] * 3
    by_line = sum(
        (x.quantize(cent, rounding=ROUND_HALF_UP) for x in amounts),
        Decimal("0"),
    )
    by_total = sum(amounts, Decimal("0")).quantize(
        cent, rounding=ROUND_HALF_UP
    )
    print("round_each_line:", by_line)
    print("round_total:", by_total)

本机执行的真实输出：

float_sum: 0.30000000000000004
from_float: 0.1000000000000000055511151231257827021181583404541015625
decimal_sum: 0.3
2.665 HALF_UP: 2.67 HALF_EVEN: 2.66
-2.665 HALF_UP: -2.67 HALF_EVEN: -2.66
round_each_line: 1.02
round_total: 1.01

舍入模式要写进规则，而不是依赖默认值

quantize(Decimal("0.01")) 表示把结果调整到分对应的小数位。示例显式传入 rounding，避免上下文默认设置悄悄改变结果。

ROUND_HALF_UP 取最近值，恰好处于中点时向远离零的方向舍入，所以 2.665 得到 2.67，-2.665 得到 -2.67。ROUND_HALF_EVEN 在中点时选择末位为偶数的结果，所以上面分别得到 2.66 和 -2.66。它们都是明确的规则，不能仅凭“保留两位”判断应该选哪一种。

退款、折扣和负数金额同样需要纳入约定。不要只用正数样例验证，也不要认为 Python 的 round() 一定采用常说的四舍五入。应先确认合同、计价规范或财务口径，再把规则写进代码与边界用例。

逐行舍入与汇总舍入可能相差一分钱

示例中的三笔金额都是 0.335。如果每笔先保留到分，每笔变成 0.34，合计是 1.02；如果先把原值合计为 1.005，再按 ROUND_HALF_UP 保留到分，总额就是 1.01。

这不是 Decimal 算错了，而是两条计算路径表达了不同业务口径。若明细本身就是需要结算的金额，通常应按明确规则生成各行金额再汇总；若只对最终总额结算，则可在最后舍入。具体采用哪种，应由业务约定决定，并让账单展示、后端计算和对账程序保持一致。

精度、存储与接口也要统一

ctx.prec = 28 指的是运算使用的有效数字精度，并不是保留二十八位小数。大数乘除、利率分摊等场景需要根据数值范围选择精度；示例使用 localcontext()，让设置只影响当前代码块。

在同一条金额计算链路中，应保持 Decimal 类型，避免又与 float 混算。向 JSON 或外部系统传值时，可以使用约定好的十进制字符串；只处理固定最小货币单位时，也可以约定整数分。两种方式都需要把单位、允许小数位、舍入时点和负数规则写清楚。

外部输入还需要单独校验。能被构造成 Decimal 不代表它就是合法金额，例如特殊值 NaN 和 Infinity 也属于该类型支持的表示。业务入口应检查 is_finite()，再按要求限制金额范围和小数位。空值、千位分隔符与货币符号应按接口协议处理，不能默默变成零，否则对账时很难追查数据来源。

建议把“恰好到中点”“负数退款”“多笔小额汇总”作为固定用例，并同时记录原始输入和最终结算金额。这样变更舍入规则时，可以明确观察差异，而不是只检查页面显示是否有两位小数。

可靠的金额计算不是把所有数字换成 Decimal 就结束了。让输入保真、让舍入显式、让汇总口径一致，才方便解释一分钱从哪里来，也方便在需求变化时定位影响范围。