new BigDecimal(0.1) 不等于 0.1，因为 double 的二进制浮点表示导致 0.1 存储为近似值 0.10000000000000000555…，BigDecimal(String) 或 BigDecimal.valueOf() 才能精确构造。
直接用 Double 构造 BigDecimal 会导致精度失真，根本原因是 Double 本身是二进制浮点数，无法精确表示大多数十进制小数（比如 0.1 在二进制中是无限循环小数），而 BigDecimal(String) 才能真正按你“看到的数字”来构建。
为什么 new BigDecimal(0.1) 不等于 0.1？
Double 类型在内存中以 IEEE 754 格式存储，0.1 实际被存成一个近似值：0.1000000000000000055511151231257827021181583404541015625。
所以 new BigDecimal(0.1) 实际构造的是这个“隐形”的长小数，而不是你想要的 0.1。
正确做法：优先用字符串构造
把原始数值以字符串形式传入 BigDecimal，绕过 double 的精度污染：
-
new BigDecimal("0.1")✅ 精确表示十分之一 -
new BigDecimal(Double.toString(0.1))⚠️ 可行但不推荐——依赖toString的舍入规则，且多此一举 -
BigDecimal.valueOf(0.1)✅ 推荐！这是官方封装的“安全转换”，内部就是调用Double.toString再构造，语义清晰、性能好
从源头控制：输入阶段就用字符串或整数
避免让 double 进入业务逻辑：
- 读取配置、JSON、表单等外部数据时，直接解析为
String，再转BigDecimal - 涉及金额、计数等场景，数据库字段用
DECIMAL，Java 层用String或long（单位为“分”）接收 - 如果必须从
double计算结果转BigDecimal，先用Math.round()转整数再构造，或明确指定精度和舍入模式（如BigDecimal.valueOf(d).setScale(2, RoundingMode.HALF_UP)）
检查与防御：单元测试中加精度断言
不要只断言 equals()，要验证数值含义是否符合预期：
- 用
compareTo()判断大小关系（它比equals()更适合数值比较） - 测试时用字符串构造做基准，比如：
assertThat(new BigDecimal("19.99").compareTo(BigDecimal.valueOf(19.99))).isEqualTo(0); - 对关键金额字段，打印
toString()而非doubleValue()来调试
不复杂但容易忽略——只要记住：看见 double 就警惕，要精确就走 String 或 valueOf 这条路。
