BigDecimal在HashSet/HashMap中出现“重复元素”是因为equals()同时比较数值和标度，导致1.0、1.00、1等数值相等但scale不同的实例被视作不同key；推荐统一调用stripTrailingZeros()归一化标度后再放入集合。
BigDecimal 在 HashSet 或 HashMap 中出现“重复元素”问题，根本原因不是它本身重复，而是你用了 精度不同但数值相等的 BigDecimal 实例，而它们的 equals() 返回 false，导致哈希表认为是两个不同 key —— 这违反直觉，但完全符合 BigDecimal 的设计逻辑。
为什么 equals 不按数值相等判断？
BigDecimal 的 equals() 同时比较 数值大小 和 标度（scale）。例如：
-
new BigDecimal("1.0")→ scale = 1 -
new BigDecimal("1.00")→ scale = 2 -
new BigDecimal("1")→ scale = 0
虽然三者 compareTo() 都返回 0（数值相等），但 equals() 全部互为 false。HashSet/HashMap 依赖 equals() + hashCode() 判重，所以这三个对象会被当作三个不同元素存入集合。
推荐方案：统一构造 + 不用 equals 做判重逻辑
最稳妥的做法，是在放入集合前，**强制标准化 BigDecimal 的 scale**，让数值相等的对象也满足 equals() 相等：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 用
BigDecimal.valueOf(double)或new BigDecimal(String)构造（避免new BigDecimal(double)的精度陷阱） - 存入前调用
stripTrailingZeros().setScale(0, RoundingMode.HALF_UP)等方式归一化 scale - 更常用的是：统一用
stripTrailingZeros()，它会把1.00变成1（scale=0），2.50变成2.5（scale=1）—— 保证数值相同、scale 也一致
示例：
BigDecimal a = new BigDecimal("1.00").stripTrailingZeros(); // 1
BigDecimal b = new BigDecimal("1.0").stripTrailingZeros(); // 1
BigDecimal c = new BigDecimal("1").stripTrailingZeros(); // 1
// a.equals(b) == true, a.equals(c) == true
Set<BigDecimal> set = new HashSet<>();
set.add(a); set.add(b); set.add(c); // 最终 size == 1
替代方案：用 TreeMap / TreeSet + compareTo 判重
如果业务上只关心数值是否相等（不关心 scale），可用基于比较器的有序集合：
- TreeSet 默认用
compareTo()，new BigDecimal("1.0").compareTo(new BigDecimal("1.00")) == 0 - HashMap 不支持，但可自定义
ConcurrentHashMap+ 外部同步，或封装一层用Map<bigdecimal v></bigdecimal>时统一调用stripTrailingZeros()作为 key
注意：TreeSet 的 contains()、remove() 等方法也走 compareTo()，所以不会漏判。
不推荐的“修复”方式
以下做法看似简单，实则危险：
- 重写 equals/hashCode 包装 BigDecimal（破坏不可变性 & 集合契约）
- 用 double 或 long 代替（丢失精度，违背用 BigDecimal 的初衷）
- 在 HashSet 外层手动去重（性能差、易遗漏、逻辑分散）
核心原则：尊重 BigDecimal 的语义，用 stripTrailingZeros() 主动归一化，而不是绕过它。
