必须用字符串初始化BigDecimal，因double构造会继承浮点误差导致精度丢失；正确方式是new BigDecimal("0.1")或BigDecimal.valueOf(0.1)，避免0.1+0.2≠0.3等计算错误。

直接用 double 做金额或高精度计算，结果常常“看起来对、其实错”。这不是 Java 的 bug，而是二进制浮点数的固有缺陷——它根本无法精确表示大多数十进制小数，比如 0.1、0.01、0.35。一旦参与运算，误差会累积，最终导致业务逻辑出错，比如账不平、优惠算多、分润少付。

double 为什么算不准？

因为 double 按 IEEE 754 标准用 64 位二进制存储，而像 0.1 这样的十进制小数，在二进制中是无限循环小数（类似十进制里的 1/3 = 0.333…）。系统只能截断保存近似值：

• System.out.println(0.1 + 0.2); → 输出 0.30000000000000004
• System.out.println(0.03 - 0.02); → 输出 0.009999999999999998

BigDecimal 怎么解决这个问题？

它不依赖二进制浮点规则，而是把数字拆成两部分存：一个整数（用 BigInteger）+ 一个小数点位置（scale）。例如 "12.34" 实际存为整数 1234 和 scale 2，所有运算都在整数层面进行，天然避免精度丢失。

• 加减乘除都返回新对象，原值不变，线程安全
• 支持自定义舍入方式（如 RoundingMode.HALF_UP），应对除不尽场景
• 标度（小数位数）可显式控制，适合金额统一保留两位

初始化 BigDecimal 的关键避坑点

错的初始化方式会让后续所有计算“从起点就失真”：

• ❌ new BigDecimal(0.1) —— 先用 double 表示 0.1 就已失真，再包装也救不回来
• ✅ new BigDecimal("0.1") —— 字符串无转换损耗，最稳妥
• ✅ BigDecimal.valueOf(0.1) —— 内部转字符串再构造，日常够用且写法简洁

实际用法中的几个硬性习惯

光创建对还不够，比较和运算也要守规矩：

• 比较大小别用 equals()，用 compareTo() —— 它只比数值，不比 scale
• 除法必须指定精度和舍入模式：a.divide(b, 2, RoundingMode.HALF_UP)
• 加减乘建议统一 scale，比如金额运算前先调用 setScale(2, RoundingMode.HALF_UP)