new BigDecimal(double)会精度丢失，因double是二进制浮点数，0.1在二进制中无限循环，JVM先按IEEE 754近似表示再传入BigDecimal；正确做法是用字符串构造（如new BigDecimal("0.1")）或BigDecimal.valueOf(0.1)。
为什么 new BigDecimal(double) 会精度丢失
直接用 new BigDecimal(0.1) 得到的不是精确的 0.1，而是 0.1000000000000000055511151231257827021181583404541015625。这是因为 double 本身是二进制浮点数，0.1 在二进制中是无限循环小数，JVM 先按 IEEE 754 表示它，再把这个“已经失真”的值传给 BigDecimal 构造器——相当于把错误原样封装了。
正确做法只有一条：从字符串构造。
-
new BigDecimal("0.1")✅ 精确 -
BigDecimal.valueOf(0.1)✅ 内部调用Double.toString()转成字符串再构造，比new BigDecimal(double)安全得多 -
new BigDecimal(0.1)❌ 避免使用
加减乘除必须用方法，不能用运算符
Java 不支持 BigDecimal 的算术运算符重载，写 a + b 会编译报错或自动拆箱成 double 导致精度崩坏。所有计算必须显式调用方法：
BigDecimal a = new BigDecimal("1.23");
BigDecimal b = new BigDecimal("0.45");
BigDecimal sum = a.add(b); // ✅
BigDecimal diff = a.subtract(b); // ✅
BigDecimal prod = a.multiply(b); // ✅
BigDecimal quot = a.divide(b, 2, RoundingMode.HALF_UP); // ✅ 必须指定 scale 和 rounding mode
特别注意 divide()：不带 scale 和 RoundingMode 参数的重载在除不尽时直接抛 ArithmeticException，生产环境几乎不可用。
立即学习“Java免费学习笔记（深入）”；
setScale() 和 divide() 的 roundingMode 别乱选
四舍五入不是只有 RoundingMode.HALF_UP 一种。银行、财务、科学计算对舍入规则要求不同，选错会导致业务逻辑偏差：
-
RoundingMode.HALF_UP：传统“四舍五入”，如 1.5 → 2，-1.5 → -2 -
RoundingMode.HALF_EVEN（银行家舍入）：1.5 → 2，2.5 → 2，-1.5 → -2，-2.5 → -2；能减少统计偏差，金融系统常用 -
RoundingMode.CEILING：朝正无穷取整，负数慎用（-1.1→-1） -
RoundingMode.FLOOR：朝负无穷取整，-1.1→-2
一旦设定了 scale，就等于承诺“这个数最多保留几位小数”，后续参与计算时若未重新 setScale()，可能因隐式精度截断引发误差累积。
compareTo() 才是安全的相等判断
别用 equals() 判断两个 BigDecimal 是否数值相等。因为 new BigDecimal("1.0").equals(new BigDecimal("1")) 返回 false——它们的 scale 不同（1.0 是 1，1 是 0），而 equals() 同时比较数值和 scale。
正确方式永远是：
if (a.compareTo(b) == 0) {
// 数值相等
}
另外，compareTo() 可用于排序、TreeSet/TreeMap 键比较，天然支持任意精度下的大小判定。
最常被忽略的是：哪怕你全程用字符串构造、用方法计算、设好 roundingMode，只要在某个环节用了 equals() 或漏了 setScale()，前面所有努力都可能白费。
