新手必看：避免Double构造BigDecimal失真技巧

新手在使用BigDecimal处理精确数值（尤其是金额）时，常因误用new BigDecimal(double)导致精度失真——根本原因在于double本身无法精确表示0.1等十进制小数，会将0.1转为近似值再构造出“隐形长小数”的BigDecimal；真正安全的做法是优先采用字符串构造（new BigDecimal("0.1")）或官方推荐的BigDecimal.valueOf(0.1)，并从数据输入源头就避免double介入，配合严谨的测试验证，才能确保金融计算等场景的绝对准确。

直接用 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 这条路。

到这里，我们也就讲完了《新手必看：避免Double构造BigDecimal失真技巧》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！