Java BigDecimal 为什么比较不相等？分清数值和小数位

Java BigDecimal 的 2.0 和 2.00 数值相同，但 equals 还会比较 scale，因此结果可能是 false。处理金额时应先明确需要比较数值还是比较表示形式，再选择 compareTo、equals 和集合类型。本文用同一组对象运行比较、HashSet 和 TreeSet，展示“相等”在不同语境中的含义。还会把比较结果放入集合和门槛判断中，检查相等语义是否与业务规则一致。为了便于复现，文中会把BigDecimal 比较、equals、compareTo分别落到输入、判断和输出三个位置，并用边界样例说明何时应该接受、拒绝或继续排查；同时明确讨论scale与金额计算。

BigDecimal 的数值相等与小数位 scale 分开比较

一、构造方式决定精度基础

new BigDecimal(0.1)会把二进制浮点误差带进十进制对象，金额应优先用字符串或BigDecimal.valueOf。构造完成后打印toPlainString和scale，先确认对象内部表示再比较。

如果需要补齐基础概念，可先阅读Java 教程，再回到下面的示例核对结果。

import java.math.BigDecimal;
import java.util.*;
BigDecimal a=new BigDecimal("2.0");
BigDecimal b=new BigDecimal("2.00");
System.out.println(a.toPlainString()+" scale="+a.scale());

new BigDecimal(0.1)会把二进制浮点误差带进十进制对象，金额应优先用字符串或BigDecimal.valueOf。金额单位和小数位是不同概念，不能靠格式化结果猜内部值。

二、equals关注对象表示

BigDecimal.equals要求数值和scale都相同，所以2.0和2.00不相等。它适合需要比较精确表示的场景，例如要求小数位格式一致的配置对象；金额数值判断通常不应直接调用equals。

System.out.println(new BigDecimal("2.0").equals(new BigDecimal("2.00")));

BigDecimal.equals要求数值和scale都相同，所以2.0和2.00不相等。把equals误当成数学相等，是最常见的判断错误。

三、compareTo关注数值

compareTo忽略scale，只要数值相同就返回0。金额是否达到门槛、余额是否足够等业务比较，应围绕compareTo写成清楚的条件，并在代码评审中说明。

如果需要补齐基础概念，可先阅读JSON 数据格式教程，再回到下面的示例核对结果。

BigDecimal limit=new BigDecimal("100.00");
BigDecimal paid=new BigDecimal("100.0");
System.out.println(paid.compareTo(limit)==0);

compareTo忽略scale，只要数值相同就返回0。不要把compareTo的返回值直接当作-1或1，契约只保证小于、等于、大于。

四、集合让差异更明显

HashSet使用equals和hashCode，2.0和2.00会被视为不同元素；TreeSet依赖compareTo，可能把它们视为同一个。集合选择要与业务定义一致，否则去重结果会让人困惑。

Set<BigDecimal> hash=new HashSet<>(List.of(new BigDecimal("2.0"),new BigDecimal("2.00")));
Set<BigDecimal> tree=new TreeSet<>(List.of(new BigDecimal("2.0"),new BigDecimal("2.00")));
System.out.println(hash.size()+"/"+tree.size());

HashSet使用equals和hashCode，2.0和2.00会被视为不同元素；TreeSet依赖compareTo，可能把它们视为同一个。若业务需要统一scale，可在进入集合前用setScale明确舍入规则。

五、边界测试与排错记录

运行2.0与2.00的equals、compareTo、hashCode、HashSet和TreeSet结果；再测试0.1的字符串构造与valueOf构造。增加100.00、99.999的门槛比较，明确RoundingMode。测试结果写入表格，避免只截一个布尔值。

在“Java BigDecimal 为什么比较不相等？分清数值和小数位”这个问题上，把测试结果按“输入、实际输出、预期输出、结论”记录下来；出现失败时保留原始错误和运行环境，不要只截取最后一行。金额和精度问题同时涉及构造方式、比较契约和集合行为，不能只看一次布尔结果就下结论。

常见误区与选择建议

不要用double构造金额；不要只把BigDecimal转成字符串比较；不要在没有舍入规则时setScale；不要认为TreeSet和HashSet的相等语义自动一致；不要用格式化展示结果替代业务计算。另外，比较前要统一金额单位和舍入时机，记录输入精度、舍入模式与输出精度；如果跨服务传输，还要约定字符串格式，避免一个服务补零而另一个服务直接按对象相等判断。接口文档也应给出 2.0、2.00、0.1 和负数等边界样例，测试报告同时保留数值与 scale。评审时再核对集合行为。

落地检查清单

为BigDecimal 比较准备一份最小正常输入和一份已知失败输入，先固定环境再比较结果。
检查equals的边界，明确哪些情况应接受、拒绝或继续排查。
记录compareTo的判断依据，避免错误被默认值、静默重试或格式化输出掩盖。
回归时一次只改一个变量，并把失败样例保留在测试目录。
交接时写明版本、命令、输入、输出和已知限制，让下一位维护者能复现结论。
对照正常输出与失败输出，确认错误信息能指出具体字段、路径、版本或状态，而不是只返回“失败”。
若规则发生变化，先更新样例和预期结果，再修改实现，避免测试通过但验收标准已经悄悄改变。
最后记录哪些情况尚未覆盖，把它们列为待确认项，不用默认值替代未知结论。

动手练习

先运行正文中的正常样例，保存完整输出。
只改变BigDecimal 比较相关的一个输入，确认失败位置符合预期。
再改变equals，比较错误信息是否仍然可定位。
关闭一项校验或配置，确认测试能够主动失败。
恢复配置并重跑，检查结果是否回到基线。
把一次失败记录整理成可交接的复现步骤。
将尚未覆盖的边界加入下一轮回归清单。

结果怎么判读

输出符合预期且日志完整：记录为通过，并保留输入样例。
输出不符合预期但错误位置清楚：记录为可修复失败，先定位规则。
输出看似成功但缺少关键字段：不能放行，补充边界校验。
同一输入在不同环境结果不同：先比较版本、配置和依赖。
修改后正常样例通过、失败样例消失：优先检查错误是否被吞掉。
只有把BigDecimal 比较、equals和compareTo的证据一起保存，结论才适合交接。

补充记录：本篇的scale需要结合实际项目约束解释，不能只凭示例中的单个返回值判断所有场景。

金额比较还应在接口边界统一小数位和舍入策略，并把约定写入测试样例。

同一对数值在不同语境下的结果

总结

BigDecimal的差异来自数值和scale两个维度。金额门槛通常用compareTo，表示和对象一致性才考虑equals；集合选型、构造方式和舍入规则必须一起设计。

延伸学习

常见问题

Q：金额比较应该用equals吗？

A：通常比较数值时用compareTo()==0，并先确定舍入和scale规则。

Q：为什么TreeSet数量和HashSet不同？

A：两者使用的相等依据不同，TreeSet依据compareTo，HashSet依据equals和hashCode。