Java BigDecimal 金额比较为什么会误判：scale 统一与集合去重边界

订单金额明明都是 10 元，结算服务却把同一条优惠结果判成“金额变化”，原因往往不是计算错了，而是把 BigDecimal 的数值比较和对象相等混在了一起。new BigDecimal("1.0") 与 new BigDecimal("1.00") 的数值相同，scale 却不同；在 Java 里，compareTo 和 equals 因此会给出不同结论。

金额大小比较用 compareTo；需要进入 HashSet、HashMap 或做稳定快照比较时，先按业务精度统一 scale，再使用 equals 或集合键。

线上误判是怎样发生的

假设订单服务接收了两个优惠计算结果，日志里分别记录为 10.0 和 10.00。如果校验代码写成下面这样，业务会认为金额发生变化：

BigDecimal oldAmount = new BigDecimal("10.0");
BigDecimal newAmount = new BigDecimal("10.00");

if (!oldAmount.equals(newAmount)) {
    throw new IllegalStateException("订单金额发生变化");
}

这段代码并没有违反 BigDecimal 的约定。问题在于，业务要判断的是“金额数值是否相等”，而 equals 判断的是“数值和 scale 是否都相等”。先把症状拆开，后面的修复才不会变成到处替换方法名。

真正的分界线：数值、scale 和对象相等

BigDecimal 用无标度整数和 scale 表示一个十进制数。1.0 的 scale 是 1，1.00 的 scale 是 2；它们都表示数值 1，但表示方式不同。

BigDecimal a = new BigDecimal("1.0");
BigDecimal b = new BigDecimal("1.00");

System.out.println(a.compareTo(b) == 0); // true
System.out.println(a.equals(b));         // false
System.out.println(a.scale());           // 1
System.out.println(b.scale());           // 2

可以把两个方法记成两种问题：compareTo 回答“金额大小是否相同”，equals 回答“这两个 BigDecimal 的数值和精度表示是否都相同”。退款金额、折扣金额和门槛金额的业务判断，通常属于前一个问题。

金额判断应该怎么写

单纯判断相等时，最小写法是：

static boolean sameAmount(BigDecimal left, BigDecimal right) {
    return left != null && right != null && left.compareTo(right) == 0;
}

if (sameAmount(oldAmount, newAmount)) {
    System.out.println("金额数值一致");
}

判断大小也沿用同一套规则：小于用 compareTo(...) ，大于用 compareTo(...) > 0。不要先转成 double；一旦经过二进制浮点数，原本的十进制金额边界又会被引入新的误差。

为什么 HashSet 去重还会留下两条金额

HashSet 依赖 equals 和 hashCode。由于 1.0 与 1.00 的 scale 不同，它们可以同时进入集合：

Set amounts = new HashSet();
amounts.add(new BigDecimal("1.0"));
amounts.add(new BigDecimal("1.00"));

System.out.println(amounts.size()); // 2

如果业务定义是“同一币种、同一金额数值只能保留一条”，应先把金额归一化到明确的业务精度，再交给集合。

static BigDecimal moneyKey(BigDecimal value) {
    return value.setScale(2, RoundingMode.UNNECESSARY);
}

Set amounts = new HashSet();
amounts.add(moneyKey(new BigDecimal("1.0")));
amounts.add(moneyKey(new BigDecimal("1.00")));

System.out.println(amounts.size()); // 1

RoundingMode.UNNECESSARY 会在输入超过两位小数时直接报错，这适合金额已经要求两位小数、且不允许静默舍入的订单边界。如果业务允许四舍五入，应在入账规则明确的位置完成舍入，而不是为了让集合去重通过就随手改 scale。

修复后要验收哪些边界

测试不要只覆盖 1.0 和 1.00。至少补上零、负数、尾随零、超过业务精度和空值策略：

assert sameAmount(new BigDecimal("0"), new BigDecimal("0.00"));
assert sameAmount(new BigDecimal("-2.5"), new BigDecimal("-2.50"));
assert !sameAmount(new BigDecimal("10.00"), new BigDecimal("10.01"));
assert moneyKey(new BigDecimal("3.20")).equals(new BigDecimal("3.20"));

还要确认数据库列精度、JSON 序列化和日志展示是否与业务规则一致。展示层可以保留用户输入的尾随零，但作为幂等键、缓存键或集合键时，应该使用同一套归一化函数。

常见问题

BigDecimal 比较金额能直接用 equals 吗？

只有当业务明确要求数值和 scale 都一致时才适合。普通金额相等判断用 compareTo 更贴近业务含义。

stripTrailingZeros 可以代替 setScale 吗？

不能一概替代。它可能得到负 scale，例如 100.00 可能被表示为 scale 为负数的值；若系统要求固定两位小数，应该显式使用 setScale 并选择舍入策略。

为什么不建议用 new BigDecimal(double)？

double 先经过二进制浮点表示，构造出的十进制值可能带有不可见的小数尾巴。金额输入优先使用字符串或明确的整数分。

小结

BigDecimal 的坑不在于它“不能比较”，而在于比较方法回答的问题不同。把数值判断交给 compareTo，把集合键交给统一 scale 后的值，并在输入、入库和序列化边界固定金额规则，订单金额误判和重复优惠记录就会少一类。