为什么用浮点数（如float/double）存储金额会导致精度丢失？

Question

为什么用浮点数（如 `float`/`double`）存储金额会导致精度丢失？ 根本原因在于：**浮点数基于二进制科学计数法表示，而十进制小数（如 0.1、0.01）大多无法被精确表示为有限位二进制小数**。例如，`0.1` 在 IEEE 754 双精度中实际存储为近似值 `0.10000000000000000555...`，多次加减后误差累积（如 `0.1 + 0.2 != 0.3`）。金融计算要求**绝对精确的十进制算术**（如分单位整数运算），而 `float`/`double` 的舍入误差会引发对账不平、利息计算偏差、审计失败等严重问题。Java 中 `0.1f + 0.2f == 0.3f` 返回 `false`；Python 中 `sum([0.1]*10)` 不等于 `1.0`——均是典型表现。行业规范（如 PCI DSS、会计准则）明确禁止浮点类型处理货币。正确做法是：使用定点数（如 Java `BigDecimal`、C# `decimal`、Python `Decimal`）或以「最小货币单位」存为整型（如分 → `long cents = 100`）。

Answer 1

```html

一、现象层：浮点数金额计算的“诡异”行为

• Java 中：0.1f + 0.2f == 0.3f 返回 false
• Python 中：sum([0.1] * 10) == 1.0 为 False，实际值为 0.9999999999999999
• JavaScript 中：(0.1 + 0.2).toFixed(17) 输出 "0.30000000000000004"
• 数据库中：SELECT 0.1 + 0.2 = 0.3;（MySQL）返回 0（即 false）

二、表示层：IEEE 754 浮点数的二进制本质

浮点数遵循 IEEE 754 标准，以 符号位 + 指数位 + 尾数位 三段式二进制科学计数法存储：

十进制数	二进制近似表示（有限位截断）	IEEE 754 双精度实际存储值
0.1	0.00011001100110011…（无限循环）	0.1000000000000000055511151231257827021181583404541015625
0.01	0.0000001010001111010111000010100011110101110000101000…	0.0100000000000000020816681711721685132943093776702880859375

三、数学层：十进制小数无法精确映射到二进制有限小数的充要条件

一个正则十进制小数 m / 10k（其中 m, k ∈ ℤ⁺）能被精确表示为有限位二进制小数，当且仅当其最简分母的质因数只含 2（即分母可写为 2n）。而 0.1 = 1/10 = 1/(2×5) 含质因子 5 → 必然产生无限循环二进制小数。

四、误差层：舍入误差的传播与放大机制

// Java 示例：连续加法误差累积
BigDecimal exact = new BigDecimal("0.1").multiply(BigDecimal.valueOf(10));
double inexact = 0.1 * 10; // 实际为 0.9999999999999999
System.out.println(exact);     // 1.0
System.out.println(inexact);   // 0.9999999999999999

五、业务层：金融系统对“确定性”的刚性需求

• 会计准则（如 IFRS 9、ASC 835）要求利息按「精确日利率 × 天数」逐日计提，误差 > ¥0.01 即触发重算与审计异常
• PCI DSS v4.0 §4.1 明确规定：“Cardholder data must be protected in storage and transmission; monetary values must be stored using fixed-point arithmetic or integer units.”
• 跨境支付（SWIFT MT202/MT103）中金额字段为 15,2 格式（15位整数+2位小数），强制十进制对齐

六、架构层：主流语言与平台的正确实践对照表

语言/平台	推荐类型	关键特性	注意事项
Java	BigDecimal（不可变，scale-aware）	支持 HALF_UP 等 10 种舍入模式；setScale(2, RoundingMode.HALF_EVEN)	禁止使用 new BigDecimal(double) 构造器；必须用字符串构造
Go	github.com/shopspring/decimal	高精度定点运算，支持 SQL 扫描/序列化	需显式调用 .RoundFloor(2) 控制小数位

七、工程层：从「错误代码」到「生产就绪」的演进路径

graph LR
  A[原始代码：double amount = 19.99;] --> B[问题暴露：对账差¥0.01]
  B --> C[临时修复：Math.round(amount * 100) / 100.0]
  C --> D[中期方案：String → BigDecimal]
  D --> E[长期架构：Money 类型封装 + Currency + Amount + Scale]
  E --> F[基础设施：数据库 DECIMAL(19,4) + 应用层强校验拦截器]

八、合规层：监管与标准的交叉验证要求

除 PCI DSS 外，中国《金融行业信息系统安全等级保护基本要求》（JR/T 0072—2012）第 6.2.3.5 条明确规定：“涉及资金交易的数值计算，应采用定点数或整数运算，禁止使用浮点类型进行金额存储与中间计算。”欧盟 PSD2 SCA 规范亦将“金额一致性校验失败”列为强认证失败的否决项。

九、反模式警示：那些看似“够用”的危险优化

• ❌ “我只做简单加减，不会出错” → 多线程并发累加时，volatile double 仍存在非原子读写与舍入竞态
• ❌ “前端四舍五入显示就够了” → 前端 JS 的 Number.toFixed() 本身基于浮点，无法修正底层误差
• ❌ “数据库用 DECIMAL，应用层用 double 没关系” → ORM 自动转换、JSON 序列化、日志打印均可能触发隐式 double 转换

十、终极方案：领域驱动的「Money」建模范式

现代金融系统应将金额视为**值对象（Value Object）**而非原始类型：

// 示例：DDD 风格 Money 类（Java）
public final class Money implements Comparable<Money> {
  private final long centAmount;      // 绝对最小单位（分）
  private final Currency currency;    // ISO 4217 货币码
  private final int scale = 2;        // 固定小数位数
  
  public Money(long cents, Currency currency) { ... }
  public Money add(Money other) { ... } // 精确整数加法
  public BigDecimal toBigDecimal() { return BigDecimal.valueOf(centAmount, 2); }
}

```