Java BigDecimal 比较为什么不能直接用 equals

我第一次在金额筛选里遇到这个问题，是把数据库返回的 1.0 和接口参数里的 1.00 放进同一个判断，结果明明显示相同，equals 却返回了 false。这不是 BigDecimal 计算错了，而是比较目标没有说清：你要比较的是数值，还是连小数位数也要比较。

Oracle 的 BigDecimal 文档把这两个概念分开：compareTo 只比较数值；equals 还要求 scale（小数位表示）相同。因此业务上的金额、比例判断通常写成 a.compareTo(b) == 0，只有确实关心对象表示形式时才使用 equals。

先分清数值和 scale

BigDecimal 可以理解为“未缩放整数 + scale”。1.0 和 1.00 的数值都是一，但前者的 scale 是 1，后者的 scale 是 2。它们属于同一个数值 cohort，却不是同一个表示形式。

import java.math.BigDecimal;

public class DecimalCompareDemo {
    public static void main(String[] args) {
        // 用字符串保留调用方写入的小数位，避免从二进制浮点数引入额外误差。
        BigDecimal priceFromDb = new BigDecimal("1.0");
        BigDecimal priceFromRequest = new BigDecimal("1.00");

        // 数值比较忽略 scale，适合判断金额是否相等。
        boolean sameValue = priceFromDb.compareTo(priceFromRequest) == 0;
        // equals 同时比较数值和 scale，适合需要保持表示形式的场景。
        boolean sameRepresentation = priceFromDb.equals(priceFromRequest);

        System.out.println(sameValue);          // true
        System.out.println(sameRepresentation); // false
    }
}

所以“比较金额是否相等”不能机械地把 equals 当成更严谨的写法。严谨的第一步是确认业务语义：账单是否只关心支付数值，还是必须保留两位小数这一格式约束。

按业务语义选择比较方法

最常见的数值判断有三种写法。需要判断小于、等于、大于时直接读取 compareTo 的负数、零和正数结果；不要把 BigDecimal 转成 double 再比较。

import java.math.BigDecimal;

final class MoneyRules {
    private MoneyRules() {
        // 工具类不需要实例化。
    }

    static boolean isZero(BigDecimal amount) {
        // compareTo(0) 允许 0、0.0 和 0.00 按同一个数值处理。
        return amount != null && amount.compareTo(BigDecimal.ZERO) == 0;
    }

    static boolean isAtLeast(BigDecimal amount, BigDecimal limit) {
        // compareTo 小于 0 表示 amount 小于 limit，其余情况满足下限。
        return amount != null && limit != null && amount.compareTo(limit) >= 0;
    }
}

如果接口契约要求金额必须保留两位小数，可以先用 setScale(2, RoundingMode.UNNECESSARY) 做格式约束，再决定是否比较。这样“格式错误”和“数值不相等”是两个不同的错误，不会靠 equals 偶然混在一起。

处理集合和哈希边界

这个差异在集合里更容易变成线上问题。HashMap 和 HashSet 依赖 equals 与 hashCode，所以 1.0 与 1.00 可以成为两个不同的键；TreeMap 和 TreeSet 使用自然顺序，也就是 compareTo，则可能把它们视为同一个排序键。

import java.math.BigDecimal;
import java.util.HashSet;
import java.util.Set;
import java.util.TreeSet;

public class SetBoundaryDemo {
    public static void main(String[] args) {
        BigDecimal onePointZero = new BigDecimal("1.0");
        BigDecimal onePointZeroZero = new BigDecimal("1.00");

        Set hashSet = new HashSet();
        // 哈希集合遵循 equals/hashCode，因此会保留两个不同表示。
        hashSet.add(onePointZero);
        hashSet.add(onePointZeroZero);

        Set treeSet = new TreeSet();
        // 有序集合遵循自然顺序，数值相等的表示会被当成同一排序键。
        treeSet.add(onePointZero);
        treeSet.add(onePointZeroZero);

        System.out.println(hashSet.size()); // 2
        System.out.println(treeSet.size()); // 1
    }
}

Oracle 文档特别提醒过 BigDecimal 的自然顺序与 equals 不一致。若系统需要统一金额键，先约定规范化策略，例如统一到固定 scale，再把规范化后的值放入集合；不要让不同模块各自决定使用哪种集合。

固定输入和测试策略

金额对象尽量从字符串、整数分或数据库明确的十进制字段构造。new BigDecimal(0.1) 表达的是二进制浮点数的精确十进制展开，不等于开发者通常以为的十进制 0.1。

发布前至少覆盖以下边界：1.0 与 1.00 的数值比较、不同 scale 的零值、负数比较、固定 scale 校验，以及同一组数据分别进入 HashSet 和 TreeSet 后的数量差异。测试名称要写出比较语义，例如“数值相等但表示不同”，不要只写“BigDecimal equals 测试”。

常见问题

什么时候仍然应该使用 equals？

当 scale 本身就是业务信息，例如报表格式、金额精度协议或需要区分输入表示形式时，可以使用 equals。此时要把这个约定写进接口和测试，而不是让调用者猜。

normalize 后再 equals 可以吗？

可以，但 normalize 必须是明确的领域规则：固定 scale、舍入模式和空值策略都要先确定。只为了让测试通过而随意调用 stripTrailingZeros()，可能改变后续格式化和序列化表现。

一句话总结：数值是否相等用 compareTo(...) == 0，表示形式是否完全相同才用 equals；进入集合前再确认集合采用的是哈希语义还是自然排序语义。