我用 BigDecimal 的 equals 判断两个金额是否相等,2.0 和 2.00 明明都是两块钱,它却告诉我不相等:一次 BigDecimal.equals 把小数位也算进相等的深度复盘
那个 bug 是金额比对"明明相等却判不等"才暴露的:我用 BigDecimal 表示金额(为了精确,不用 float,这是对的)。某处要判断两个金额是否相等,我很自然地用了 equals:amountA.equals(amountB)。功能大体能用,可线上偶发:两个数值上明明相等的金额(比如一个是 2.0、一个是 2.00,都是两块钱),equals 却返回 false(判为不相等),导致后面"金额一致才放行"的逻辑卡住。我盯着"2.0 不等于 2.00?"愣住了。我查清 BigDecimal.equals 的语义,才看明白,后背发凉:问题出在 BigDecimal 的 equals 不只比较"数值",还比较"scale(小数位数/精度)"。BigDecimal 在内部,用"无标度值 + scale(小数点后位数)"来表示一个数:2.0 是"无标度值 20,scale 1",2.00 是"无标度值 200,scale 2";它的 equals 规定:只有"无标度值和 scale 都相同"才算 equals 相等;所以 2.0 和 2.00 虽然数值相等,但scale 不同(1 vs 2),equals 就判为 false;而我想要的是"数值相等",却用了一个"连小数位都要一样"的 equals,自然出错。根本原因是:BigDecimal.equals 对"相等"的定义,包含了 scale(精度),数值相等但精度不同(2.0 vs 2.00)就判不等;要比较"数值是否相等"应该用 compareTo() == 0。问题的根,是用 BigDecimal.equals 比较金额数值:它把 scale 也算进相等,2.0 和 2.00 数值相等但 scale 不同就判 false。这篇就把这次"BigDecimal.equals 比 scale"的坑,从头到尾复盘一遍。
故障现场:2.0 和 2.00,equals 判不等
问题在于 BigDecimal.equals 把 scale 也算进相等:
// ✗ 出问题的代码: 用 equals 比较两个BigDecimal金额是否相等
BigDecimal a = new BigDecimal("2.0");
BigDecimal b = new BigDecimal("2.00");
System.out.println(a.equals(b)); // ✗ false! 2.0 和 2.00 居然不相等?!
// 导致 "if (amountA.equals(amountB)) 才放行" 的逻辑, 在金额数值相同但写法/scale不同时卡住。
// 为什么? BigDecimal.equals 比较的是 "无标度值 + scale", 不只是数值:
// - BigDecimal内部用 (unscaledValue, scale) 表示: 数值 = unscaledValue × 10^(-scale);
// 2.0 → unscaledValue=20, scale=1;
// 2.00 → unscaledValue=200, scale=2;
// - equals规定: 无标度值【和】scale都相同才相等;
// → 2.0 和 2.00: 数值相等(都是2), 但scale不同(1 vs 2) → equals返回false。
// ✓ 比较"数值是否相等", 要用 compareTo:
System.out.println(a.compareTo(b) == 0); // ✓ true! compareTo只比数值, 忽略scale
// compareTo 返回 -1/0/1, ==0 表示数值相等(不管scale)。
// 一个对比(直观感受BigDecimal.equals的"严格"):
new BigDecimal("0").equals(new BigDecimal("0.0")); // ✗ false (scale 0 vs 1)
new BigDecimal("0").compareTo(new BigDecimal("0.0")) == 0; // ✓ true
// 为什么BigDecimal.equals这么设计? 因为scale是BigDecimal的一部分信息(它要精确表示"有几位小数"),
// "2.0"和"2.00"在BigDecimal看来是"精度不同的两个值"; equals严格地认为它俩不是"同一个对象值"。
// → 但我们做业务通常只关心"数值相等", 这时该用compareTo。
// 关键: BigDecimal.equals 比较"无标度值+scale"(数值相等但小数位不同就判false, 如2.0≠2.00);
// 比较"数值是否相等"要用 compareTo()==0(只比数值、忽略scale) —— 别用equals比BigDecimal数值。
第一次看到 new BigDecimal("2.0").equals(new BigDecimal("2.00")) 是 false 时,我又荒谬又恍然:"2.0 和 2.00 不就是两块钱吗?怎么会不相等?完全没想到 BigDecimal 的 equals 还要看小数点后有几位。"这个坑最隐蔽的地方在于:它违背了"equals 就是判数值相等"的直觉——我们用惯了 equals 判内容相等,根本想不到 BigDecimal 的 equals 把"精度(scale)"也算进去了;而且它只在"数值相等但小数位写法不同"时才暴露(2.0 vs 2.00、0 vs 0.0),很多时候 scale 恰好一样、碰巧没事。下面就来拆解,BigDecimal 该怎么正确比较。
第一件事:搞懂 BigDecimal 的 equals 与 compareTo
我顺着这次事故,把 BigDecimal 的相等比较彻底理清了。
BigDecimal 的 equals 和 compareTo 有什么区别?
【核心: BigDecimal.equals比"无标度值+scale"(2.0≠2.00, 精度不同就不等); compareTo()==0只比数值(忽略scale); 比数值用compareTo, 别用equals】
1. BigDecimal的内部表示: unscaledValue(无标度值) + scale(小数位数)
- 数值 = unscaledValue × 10^(-scale);
- 2.0 = 20 × 10^(-1) → (20, 1); 2.00 = 200 × 10^(-2) → (200, 2);
- → 同一个数值, 可以有不同的scale(不同的"精度表示")。
2. equals: 比较 unscaledValue 和 scale 是否都相同
- 要求"无标度值和scale都一样"才相等;
- → 2.0(20,1) 和 2.00(200,2): 数值相等但scale不同 → equals为false;
- 它把"精度/小数位数"也当成了"相等"的一部分。
3. compareTo: 只比较数值大小, 忽略scale
- compareTo返回负/0/正, == 0 表示"数值相等"(不管scale);
- → 2.0.compareTo(2.00) == 0 为 true;
- 业务上判"金额是否相等", 用这个。
4. 怎么选:
- 判"数值是否相等": 用 compareTo(other) == 0(几乎所有业务场景都该用这个);
- 只有当你确实关心"数值和精度都一样"时, 才用equals(很少);
- 排序: BigDecimal实现了Comparable, 用compareTo(TreeMap/TreeSet/sort都用它, 所以没这个坑)。
5. 连带的坑: BigDecimal当HashMap的key / 放HashSet
- 因为equals/hashCode基于(unscaledValue, scale), 2.0和2.00会被当成不同的key!
- → 用BigDecimal当key要小心(2.0和2.00存进去是两个key); 或统一scale(setScale)后再用。
6. 别用float/double构造BigDecimal(同554篇): new BigDecimal(0.1)会把double误差带进来; 用字符串 new BigDecimal("0.1")。
一句话: BigDecimal.equals比"无标度值+scale"(2.0和2.00数值相等但scale不同就判false); 比较数值是否相等要用
compareTo()==0(忽略scale); 业务判金额相等用compareTo, 别用equals; 当key/去重也要注意scale影响相等。
这套认知,是整个坑的根。BigDecimal 的内部表示:unscaledValue(无标度值)+ scale(小数位数)——数值=unscaledValue×10^(-scale),同一个数值可有不同的 scale(2.0 是 (20,1)、2.00 是 (200,2))。equals:比较 unscaledValue 和 scale 是否都相同——把"精度/小数位数"也算进相等,所以 2.0 和 2.00 数值相等但 scale 不同就判 false。compareTo:只比数值大小、忽略 scale——compareTo() == 0 表示数值相等,业务判金额相等用它。怎么选:判数值是否相等用 compareTo(other)==0(几乎所有业务场景);只有需要数值和精度都一样才用 equals(很少)。连带的坑:BigDecimal 当 HashMap key/放 HashSet,因 equals/hashCode 基于(unscaledValue,scale),2.0 和 2.00 会被当成不同的 key,要统一 scale。别用 double 构造(new BigDecimal(0.1) 带误差,用字符串)。一句话:BigDecimal.equals 比"无标度值+scale"(2.0 和 2.00 数值相等但 scale 不同就判 false);比较数值是否相等要用 compareTo()==0(忽略 scale);业务判金额相等用 compareTo,别用 equals;当 key/去重也要注意 scale 影响相等。
第二件事:正解——比较数值用 compareTo()==0,统一 scale,字符串构造
搞懂了原理,正解就清晰了:比较 BigDecimal 数值是否相等用 compareTo()==0;需要统一精度时用 setScale;构造用字符串而非 double;当 key/去重要先统一 scale。
// ====== 正解一: 比较数值是否相等, 用 compareTo() == 0 ======
BigDecimal a = new BigDecimal("2.0");
BigDecimal b = new BigDecimal("2.00");
if (a.compareTo(b) == 0) { // ✓ true: 只比数值, 忽略scale, 2.0和2.00判相等
// 金额相等的逻辑
}
// 大小比较也用compareTo: a.compareTo(b) < 0 / > 0
// 判是否为0: amount.compareTo(BigDecimal.ZERO) == 0(别用 equals(BigDecimal.ZERO))
// ====== 正解二: 需要统一精度时, 用 setScale ======
BigDecimal x = a.setScale(2, RoundingMode.HALF_UP); // 统一成2位小数(四舍五入)
// 统一scale后, equals和compareTo就一致了; 金额常统一成2位(分)。
// ====== 正解三: 构造用字符串(同554篇), 别用double ======
BigDecimal ok = new BigDecimal("0.1"); // ✓ 精确
// BigDecimal bad = new BigDecimal(0.1); // ✗ 把double的误差带进来 → 0.1000000000000000055...
BigDecimal fromDouble = BigDecimal.valueOf(0.1); // valueOf(double)内部用Double.toString, 较安全
# ====== 用 BigDecimal 的要点 ======
# 1. 比较数值是否相等: 用 compareTo(other) == 0(忽略scale); 别用 equals(它把scale也算进相等);
# 2. 大小比较/排序: 用 compareTo(它比数值, 没坑);
# 3. 判是否为0: compareTo(BigDecimal.ZERO) == 0, 别用 equals(BigDecimal.ZERO)(0 vs 0.0会false);
# 4. 需要统一精度: 用 setScale(n, RoundingMode), 金额常统一成2位小数; 统一后equals/compareTo一致;
# 5. 构造用字符串 new BigDecimal("0.1") 或 BigDecimal.valueOf(double), 别用 new BigDecimal(double)(同554篇);
# 6. 当HashMap的key/放HashSet: 注意2.0和2.00是不同key(equals/hashCode含scale), 先统一scale;
# 7. 运算要指定舍入: divide等可能除不尽抛ArithmeticException, 要给RoundingMode和精度。
# ====== 一个原则 ======
# - 用一个类型/方法前, 搞清它对"相等"的【确切定义】——是比值、比引用、还是比值+其他属性(如scale)?
# - 别想当然以为"equals就是我以为的那种相等"; 不同类型的equals可能有不同的语义。
# 核心: BigDecimal比数值是否相等用compareTo()==0(忽略scale), 别用equals(含scale); 统一精度用setScale、
# 构造用字符串、当key注意scale; 用任何类型的equals前, 先搞清它对"相等"的确切定义。
修复的核心,是"比数值用 compareTo()==0,统一精度用 setScale"。正解一:比较数值是否相等用 compareTo() == 0——只比数值忽略 scale,2.0 和 2.00 判相等;判是否为 0 用 compareTo(BigDecimal.ZERO) == 0。正解二:需要统一精度用 setScale(如金额统一成 2 位小数,统一后 equals 和 compareTo 一致)。正解三:构造用字符串(new BigDecimal("0.1") 或 BigDecimal.valueOf(double),别用 new BigDecimal(double))。要点:比数值用 compareTo()==0、大小/排序用 compareTo、判 0 别用 equals、统一精度用 setScale、构造用字符串、当 key 注意 scale、运算指定舍入。原则:用一个类型/方法前搞清它对"相等"的确切定义(比值/比引用/比值+其他属性),别想当然以为 equals 就是你以为的那种相等。归根结底:BigDecimal 比数值是否相等用 compareTo()==0(忽略 scale),别用 equals(含 scale);统一精度用 setScale、构造用字符串、当 key 注意 scale;用任何类型的 equals 前,先搞清它对"相等"的确切定义。
第三件事:Java 中其他"equals/比较"相关的坑
排查后我把 Java 中其他和 equals、比较相关的坑也系统梳理了一遍。
Java equals/比较相关的其他坑
# 1. BigDecimal.equals比scale(本文): 2.0≠2.00。→ 比数值用compareTo()==0。
# 2. ==比较对象/字符串/Integer(同353篇): ==比引用。→ 内容比较用equals。
# 3. equals没重写hashCode(同557篇): HashMap存了取不到。→ 一起重写。
# 4. 浮点用==或equals比(同554篇): 精度误差。→ 钱用整数分/BigDecimal+compareTo。
# 5. compareTo和equals不一致: 有些类compareTo==0但equals!=(如BigDecimal), 影响TreeMap/TreeSet去重。→ 留意。
# 6. 用了compareTo做相等但类没正确实现Comparable: → 确认实现正确。
# 7. Optional/包装类型的相等: 注意null和值的比较。→ 用Objects.equals。
# 8. 数组的equals是身份比较: Arrays.equals才比内容。→ 比内容用Arrays.equals。
# 共同根源: "相等/比较"看似简单, 但不同类型对"相等"有不同的【定义】(比值?比引用?比值+精度?);
# 而我们常常带着"equals就是我以为的相等"的想当然去用, 没搞清这个具体类型的equals到底比的是什么——
# 于是在它的定义和我们的预期不符的地方(如BigDecimal含scale)栽跟头。
# 核心: 用任何类型的equals/compareTo前, 搞清它对"相等/比较"的确切定义(读文档); 别想当然;
# BigDecimal比数值用compareTo、对象内容比较用equals(并实现对)、浮点别用==、数组用Arrays.equals。
排查让我把 equals/比较的其他坑也梳理清了。一、BigDecimal.equals 比 scale(本文)。二、== 比较对象/字符串/Integer。三、equals 没重写 hashCode。四、浮点用 ==/equals 比。五、compareTo 和 equals 不一致。六、Comparable 实现不当。七、包装类型/Optional 的相等。八、数组的 equals 是身份比较。它们的共同根源是:"相等/比较"看似简单,但不同类型对"相等"有不同的定义(比值?比引用?比值+精度?);而我们常常带着"equals 就是我以为的相等"的想当然去用,没搞清这个具体类型的 equals 到底比的是什么——于是在它的定义和我们的预期不符的地方(如 BigDecimal 含 scale)栽跟头。核心是:用任何类型的 equals/compareTo 前,搞清它对"相等/比较"的确切定义(读文档);别想当然;BigDecimal 比数值用 compareTo、对象内容比较用 equals(并实现对)、浮点别用 ==、数组用 Arrays.equals。下面这张图,是这次 BigDecimal.equals 坑的成因与解法:
第四件事:BigDecimal equals vs compareTo 对比表
这次踩坑后,我把 BigDecimal 的 equals 和 compareTo 对比成一张表。
| 维度 | equals | compareTo() == 0 |
|---|---|---|
| 比较什么 | 无标度值 + scale(数值+精度) | 只比数值大小 |
| 2.0 vs 2.00 | false(scale 不同) | true(数值相等) |
| 0 vs 0.0 | false | true |
| 适合 | 要求数值和精度都一样(少) | 判数值是否相等(业务常用) |
| 当 key/去重 | 2.0 和 2.00 是不同 key | (不用于 key) |
这张表把两者钉清了。核心是:同一个"比较两个 BigDecimal 是否相等"的需求,equals 和 compareTo 给出不同的答案,因为它们对"相等"的定义不同——equals 认为"相等"是"连精度都一样"(它把 scale 视为值的一部分),compareTo 认为"相等"是"数值大小一样"(忽略精度);我用错, 是因为我心里的"相等"(数值相等)和 equals 的"相等"(数值+精度相等)不是一回事。它给我的最大启发是:"相等"不是一个唯一的、绝对的概念——它取决于"你关心哪些方面的一致";同样两个东西,在"关心 A 方面"时是相等的,在"还关心 B 方面"时可能就不等了(2.0 和 2.00:关心数值时相等、还关心精度时不等);所以"判断两个东西是否相等"前,要先想清"我说的'相等'到底是哪种相等?我关心哪些维度的一致?"。这给了我一种处理"相等判断"的清醒:做任何"相等性判断"时,要先明确"我要的是哪个维度/层面的相等"(数值相等?内容相等?身份相等?某些字段相等?),再选用'定义恰好匹配这个维度'的比较方式——而不是随手用一个 equals、却没意识到它定义的"相等"和我要的不是同一种;"想清自己要的是哪种相等、选用定义匹配的比较",是避免'相等判断'出错(明明相等却判不等、或反之)的关键。认清相等取决于关心哪些维度、判断前先想清要哪种相等再选匹配的比较——是这个 BigDecimal 坑带给我的认知。
第五件事:这次事故暴露的"精确"也有不同的维度
这次让我反思更深一层:我用 BigDecimal 是为了"精确",而它的 equals 把"精度(scale)"也当成了相等的一部分,这恰恰是它"精确"的体现。我把"数值的精确"和"表示的精确"对比成表。
| 维度 | 数值精确(我关心的) | 表示精确(BigDecimal equals 关心的) |
|---|---|---|
| 2.0 vs 2.00 | 相等(都是 2) | 不等(精度表示不同) |
| 关注点 | 这个数是多少 | 这个数被表示成几位小数 |
| 用什么比 | compareTo | equals |
| 谁更"精确" | — | equals 更"严格/信息全" |
| 本质 | 值的相等 | 值+精度的完全一致 |
这张表道出了一个微妙之处。核心是:BigDecimal.equals 之所以"反直觉地"把 2.0 和 2.00 判为不等,恰恰是因为它比我以为的更"精确/严格"——它不仅记录了"数值是多少",还记录了"这个数被表示成了几位小数(精度)",并把这个精度也纳入了"是否完全一致"的判断;"2.0"和"2.00"在它眼里, 是"同一个数值、但不同的精度表示"——它认为这俩不是"完全一样的东西";它的"较真", 在我只关心数值时显得多余, 但在某些关心精度的场景(如要区分"精确到角"和"精确到分")是有意义的。它给我的深刻启发是:"精确/严格"本身也有不同的维度和层次——一个东西在"某个维度"上精确(数值),不代表它在"另一个维度"上也一致(精度/表示);"它比我更较真"的工具(如 BigDecimal.equals 把精度也较真了),不是它错了,而是它较真的维度和我关心的维度不同;理解一个"严格的"工具时, 要搞清"它到底在'哪些维度'上严格", 别误以为它的"严格"就是我要的那种。这给了我一种使用"严格工具"的清醒:当一个工具表现得"比我预期的更严格/更较真"(把我没在意的某个维度也算进去了),先别急着觉得它"错了/不好用",而要理解"它在较真哪个维度、为什么",再判断"我的场景该用它这种严格、还是用一个只关心我在意维度的方式";"理解工具'严格在哪个维度', 按自己关心的维度选用",是用对'严格工具'的关键——它的严格不是错, 只是可能不匹配你当下的需求。认清精确有不同维度、工具的严格是较真某个维度要按自己关心的维度选用——是这个 BigDecimal 坑带给我的认知。
第六件事:比较 BigDecimal/金额时,我现在的自检习惯
现在每当我要比较 BigDecimal 或处理金额,我都会先按这张图问自己:
这张图的精髓,是"比数值用 compareTo()==0、判 0 别用 equals、当 key 统一 scale、构造用字符串"。判数值相等compareTo()==0、判 0compareTo(ZERO)==0、当 key先 setScale 统一、构造用字符串。这套习惯,让我从"金额相等随手 equals"变成了"比数值用 compareTo"——核心始终是:BigDecimal 比数值是否相等用 compareTo()==0(忽略 scale),别用 equals(含 scale);统一精度用 setScale、构造用字符串;用 equals 前先搞清它对相等的确切定义。
我立下的几条规矩
这场"2.0 不等于 2.00、金额判不等"的事故,换来了我用 BigDecimal 时,刻进骨子里的几条铁律:
- BigDecimal.equals 比较"无标度值 + scale",数值相等但 scale 不同(2.0 vs 2.00)判 false。
- 比较数值是否相等,用 compareTo(other) == 0(忽略 scale)。
- 判是否为 0 用 compareTo(BigDecimal.ZERO) == 0,别用 equals(BigDecimal.ZERO)。
- 需要统一精度用 setScale(n, RoundingMode);金额常统一成 2 位小数。
- 构造用字符串 new BigDecimal("0.1"),别用 new BigDecimal(double)(带误差)。
- BigDecimal 当 HashMap key/去重,2.0 和 2.00 是不同 key,先统一 scale。
- 用任何类型的 equals 前,搞清它对"相等"的确切定义,别想当然。
附:金额计算的一套实践小结
借这次 BigDecimal 的坑,我把团队里关于"金额怎么算才不出错"的实践,系统地整理了一份小结,贴在了项目的开发规范里。
// ====== 金额计算实践小结 ======
// 1. 表示: 金额用 BigDecimal(或整数分), 绝不用 float/double(同554篇, 精度丢失);
BigDecimal price = new BigDecimal("19.90"); // ✓ 字符串构造, 精确
// 2. 构造: 用字符串或 BigDecimal.valueOf(long), 别用 new BigDecimal(double);
// new BigDecimal(0.1) → 0.1000000000000000055...(把double误差带进来), 错!
// 3. 相等: 比数值用 compareTo()==0(忽略scale), 别用 equals(含scale, 2.0≠2.00);
boolean same = a.compareTo(b) == 0;
// 4. 判零/正负: compareTo(BigDecimal.ZERO) 的结果, 别用 equals;
if (amount.compareTo(BigDecimal.ZERO) > 0) { /* 金额为正 */ }
// 5. 除法必须指定精度和舍入: 否则除不尽会抛 ArithmeticException;
BigDecimal avg = total.divide(count, 2, RoundingMode.HALF_UP); // 保留2位, 四舍五入
// 6. 统一精度: 金额统一成2位小数(精确到分), 存库/展示前 setScale;
BigDecimal money = raw.setScale(2, RoundingMode.HALF_UP);
// 7. 数据库: 金额列用 DECIMAL(精度,标度), 别用 float/double 列(同554篇)。
这份小结的每一条,都是踩过坑换来的:用 BigDecimal/整数分而非 float、字符串构造、比数值用 compareTo 而非 equals、除法指定舍入、统一 scale、数据库用 DECIMAL。它们共同指向一个朴素的道理:金额(以及一切"差一点就出大事"的精确量)的处理,不能凭"大概差不多"的直觉,而要对它的每一个环节(表示、构造、运算、比较、舍入、存储)都用'精确、明确、无歧义'的方式——因为钱的事, 差一分、差一个 scale、差一次舍入, 累积起来都是真金白银的损失和对不平的账。把这些"精确处理金额"的规矩固化成团队规范,比每个人各自踩一遍坑,要划算得多。
写在最后
回头看,这场由"BigDecimal.equals 把 scale 也算进相等"引发的、2.0 判不等于 2.00 的事故,真正教给我的,远不止"比数值用 compareTo"这一个技巧。它让我对"'相等'这个我们以为最简单、最不言自明的概念, 其实没有唯一的答案——它取决于'站在什么角度、关心哪些方面'; 而我用我的'相等'(数值)去套别人定义的'相等'(数值+精度), 自然对不上",有了一次刻骨的体会。我栽跟头,是因为我以为"相等就是相等"——我心里只有一种"相等"(数值上一样就是相等),并理所当然地以为 equals 判的就是这种相等。可 BigDecimal 的设计者, 心里的"相等"是另一种(数值和精度都一样才相等);2.0 和 2.00, 从'数值'的角度看是相等的, 从'数值+精度表示'的角度看是不等的——它们"相等不相等", 取决于"你把'精度'算不算进去";我和 BigDecimal.equals, 不是谁对谁错, 而是我俩对"相等"的定义、关心的维度不一样, 我却拿我的定义去用了它的方法。这让我领悟到一个关于"概念的相对性"的深刻认知:很多看似"客观、唯一"的概念(相等、相同、完成、成功、好),其实都隐含着一个'从什么角度、按什么标准'的前提——"相等"要看'在哪些维度上一致',"完成"要看'按什么标准算完成';而沟通/协作的误解, 常常源于"双方对同一个概念, 隐含地用了不同的角度/标准, 却都以为自己的才是'那个唯一的'"。这给了我一种使用概念时的清醒:使用任何"看似不言自明的概念"(尤其在它由别人/某个系统定义时),要意识到"它可能有一个我没察觉的'角度/标准'前提",并去搞清"它这里说的'相等/完成/成功', 具体是按什么定义的"——而不是想当然地套用我自己的定义;"对'相等'这类概念保持'它可能有不同定义'的觉察、用前确认其确切含义",是避免'用我的标准去理解别人的概念'式误解的关键。认清相等等概念没有唯一答案取决于角度和维度、用别人定义的概念要确认其确切含义——这,是我用一次 BigDecimal.equals 的事故,换来的、关于 Java、也关于如何理解概念之相对性的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次比较两个 BigDecimal 金额时,用上 compareTo() == 0 而非 equals,那我对着那"2.0 不等于 2.00"的诡异判断排查的这段时间,就值了。
—— 别看了 · 2026