金额换成 Decimal 仍会差一分钱：输入来源、舍入模式与计算时点

摘要：金额计算使用 Decimal，不代表每一步都会自动符合结算规则。本文用 Python 标准库的独立本地实验，分别验证浮点输入、正负中点舍入、逐项取整与汇总取整的差异，并说明十进制运算精度仍需明确设置。

报价、费用分摊和账单汇总，都可能遇到“显示两位小数，结果却差一分”。排查时应把三个问题分开：程序最初读到什么数，中点往哪边舍入，以及在哪一步舍入。

从原始文本进入十进制

本次实验中，浮点表达式 0.1 + 0.2 == 0.3 为假；改用三个字符串构造的 Decimal，等式成立。原因是这些十进制小数不能用有限的二进制浮点数精确表示。

但 Decimal(0.1) 接到的是已经近似的浮点值，会精确保留它的十进制展开，并不等于 Decimal("0.1")。因此，替换类型还不够，需要检查数值来源。

用中点更容易看出影响：按 ROUND_HALF_UP 保留两位小数，Decimal("2.675") 得到2.68，Decimal(2.675) 却得到2.67，因为后者实际略小于2.675。

先调用 str() 也不能普遍恢复原意。本次把 0.1 + 0.2 转成字符串，再构造 Decimal，得到的仍是 0.30000000000000004。若接口提供原始金额文本，应从文本直接解析，避免先经过浮点计算。

接口还需约定金额单位、允许的小数位、负数意义和无效值处理。本文直接构造已知字符串，不提供通用金额解析器；几组正常输入不能证明任意外部数据都能结算。输出到JSON时也应约定使用金额字符串还是整数最小单位，避免下游再次按浮点解释。

中点规则要写在计算里

Decimal 默认上下文采用 ROUND_HALF_EVEN，中点取末位为偶数的一边；ROUND_HALF_UP 则在恰好中点时远离零。对正数可以直观理解为常见的四舍五入，对负数不能理解成“向正方向进位”。

本次显式指定模式，得到：

选择哪种规则应由业务约定决定。这里的 quantize(Decimal("0.01"), rounding=...) 明确保留百分位，并没有替系统决定币种、税则或结算政策。

同一批金额，舍入时点也会改结果

假设三条合成明细各为0.005。逐条按 HALF_UP 保留两位，每条都是0.01，合计0.03；先相加得到0.015，再舍入则是0.02。两个过程输入相同、模式相同，差别来自舍入的位置。

下面的完整片段可复现这组差异：

from decimal import Decimal, ROUND_HALF_UP, localcontext

with localcontext() as ctx:
    ctx.prec = 28
    cent = Decimal("0.01")
    amounts = [Decimal("0.005")] * 3
    per_line = sum(
        (x.quantize(cent, rounding=ROUND_HALF_UP) for x in amounts),
        Decimal("0"),
    )
    total_first = sum(amounts, Decimal("0")).quantize(
        cent, rounding=ROUND_HALF_UP
    )
    print(per_line, total_first)  # 0.03 0.02

验收需要同时写清原始明细、舍入模式、舍入层级和预期总额。若按明细结算，就核对舍入后的明细之和；若按汇总结算，就保留中间精度后处理总额。不能看到一分钱差异便任意选择较大的数。

精确解析之后，运算仍有精度边界

prec 表示运算结果的有效数字位数，不是小数位数。另一个实验把精度设为4，执行 Decimal("1234") + Decimal("0.1")，结果为1234，Inexact 与 Rounded 标志都为真；启用 Inexact 陷阱后，同一运算会抛出异常。

因此，字符串构造能保留输入，不等于后续计算拥有无限精度。示例中的28足以覆盖本组小数，业务代码仍需结合金额范围、中间运算和误差处理规则设置上下文。计划中的舍入本就可能不精确，不能不分阶段地启用陷阱。

2026年11月2日，本实验在 Windows、Python 3.12.14下实际运行八组预期观察，全部符合断言，退出码0，stderr为空。原始输出、环境和文件指纹均已本地保存。实验只涉及合成数据，没有调用云服务、处理真实账单或进行性能测量，也没有验证完整金额解析和生产结算流程。