本文详解 BigDecimal 双精度浮点数构造函数引发的精度陷阱，揭示为何 new BigDecimal(2.55) 与 new BigDecimal("2.55") 在 JUnit 断言中行为迥异，并提供安全、可靠的初始化实践方案。
本文详解 `bigdecimal` 双精度浮点数构造函数引发的精度陷阱，揭示为何 `new bigdecimal(2.55)` 与 `new bigdecimal("2.55")` 在 junit 断言中行为迥异，并提供安全、可靠的初始化实践方案。
在金融计算、精确数值比对等场景中，BigDecimal 是 Java 中保障高精度运算的首选类型。然而，一个极易被忽视的细节——构造方式的选择——会直接导致单元测试意外失败，甚至引发生产环境中的隐性精度错误。
核心问题在于：BigDecimal 提供了多个构造函数，但语义截然不同。尤其当传入 double 类型参数时（如 new BigDecimal(2.55)），其行为并非“将数字 2.55 精确表示为 BigDecimal”，而是将该 double 值的二进制浮点近似值（即 IEEE 754 表示）转换为 BigDecimal。由于 2.55 在二进制中无法精确表示，它在 double 中实际存储的是一个微小偏差的值（例如 2.54999999999999982236431605997495353221893310546875）。因此：
System.out.println(new BigDecimal(2.55)); // 输出：2.54999999999999982236431605997495353221893310546875
而 new BigDecimal("2.55") 则严格按字符串字面量解析，生成精确等于 2.55 的 BigDecimal：
System.out.println(new BigDecimal("2.55"));
// 输出：2.55回到原始测试用例：
- ✅ assertThat(finalBalance, is(new BigDecimal("2.55"))) 成功：因两边均为精确的 2.55
- ❌ assertThat(finalBalance, is(new BigDecimal(2.55))) 失败：因右侧是 2.549999...，与计算结果 2.55 不等
值得注意的是，initialBalance 和 spendingOne 使用 int 和 double 构造看似“无害”，实则风险已埋下：
- new BigDecimal(5) 安全（int → 精确）
- new BigDecimal(0.25) 不安全！虽然 0.25 在二进制中可精确表示（0.01₂），但此属特例；换成 0.1 或 0.2 就立即暴露问题。
✅ 推荐的安全初始化方式（按优先级排序）：
-
始终首选 String 构造函数
明确、可控、无歧义：BigDecimal amount = new BigDecimal("123.45"); -
使用 BigDecimal.valueOf(double)
内部先将 double 转为 String 再构造，对常见十进制数更友好（但仍有边界情况需注意）：BigDecimal amount = BigDecimal.valueOf(2.55); // 实际调用 valueOf(255, 2)
避免直接使用 new BigDecimal(double)
JDK 文档明确警告：“The results of this constructor can be somewhat unpredictable.” —— 其行为高度依赖 double 的底层表示，应视为已过时且危险的 API。
? 额外建议：
- 在团队代码规范中明文禁止 new BigDecimal(double)；
- 使用静态分析工具（如 SonarQube、ErrorProne）配置规则拦截该构造函数调用；
- 对金额、利率等关键字段，考虑封装工厂方法强制校验输入格式（如仅接受 String 或 long + scale）。
精度不是“差不多就行”，而是“必须分毫不差”。选择正确的 BigDecimal 构造方式，是从第一行代码就守护业务准确性的关键防线。
