应使用compareTo()比较BigDecimal金额，因其按数学值归一化后精确比较；equals()同时比较数值和精度，==比较引用，均不适用；需用字符串构造避免double精度误差，并确保非null。
为什么不能直接用 == 或 .equals() 比较 BigDecimal 金额
因为 BigDecimal 的 .equals() 同时比较数值和精度（scale），new BigDecimal("1.0") 和 new BigDecimal("1.00") 虽然值相等，但 .equals() 返回 false；而 == 比的是引用，基本永远是 false。金额比大小只关心“数值大小”，不关心小数位数是否一致。
compareTo() 是唯一推荐的数值比较方式
compareTo() 会先对齐 scale（按数学值归一化），再做精确比较，返回 -1、0 或 1，语义清晰且稳定。它不依赖构造方式，也不受 scale 差异干扰。
- 正确写法：
amount1.compareTo(amount2) > 0表示amount1大于amount2 - 错误写法：
amount1.equals(amount2)或amount1.doubleValue() > amount2.doubleValue()（后者有精度丢失风险） - 注意：
compareTo()不抛异常，但若任一操作数为null，会触发NullPointerException，务必提前判空
常见陷阱：构造参数类型导致意外的 scale
用 double 构造 BigDecimal（如 new BigDecimal(0.1)）会产生不可控的二进制精度误差，进而影响 compareTo() 结果——这不是方法问题，而是源头数据已失真。
- ✅ 正确：用字符串构造，
new BigDecimal("0.1")、new BigDecimal("100.00") - ❌ 危险：用 double 构造，
new BigDecimal(0.1)实际值是0.1000000000000000055511151231257827021181583404541015625 - ⚠️ 补救：若必须从 double 来，先用
String.valueOf(d)转再构造，但更建议源头就用字符串或BigInteger+scale
在业务逻辑中安全使用 compareTo() 的典型模式
金额判断常出现在条件分支、排序、校验等场景，需兼顾可读性与健壮性。
- 判断是否超限：
if (userBalance.compareTo(maxAllowed) > 0) { ... } - 升序排序（如 List.sort）：
list.sort(Comparator.comparing(b -> b.getAmount()))，前提是getAmount()返回非 nullBigDecimal - 多条件比较（先比金额，金额相同时比时间）：
amount1.compareTo(amount2) != 0 ? amount1.compareTo(amount2) : time1.compareTo(time2) - 最易忽略的一点：所有参与
compareTo()的BigDecimal必须是非 null 的——哪怕数据库字段允许为空，代码里也得统一转成BigDecimal.ZERO或显式 throw，否则线上突然 NPE
compareTo() 本身没难度，难的是确保传入它的两个值都来自可信构造路径、且全程未被意外转成 double 或 float。一旦源头污染，后面再怎么比都白搭。 
