浮点数的陷阱：你以为的 0.1 + 0.2其实不是 0.3，BigDecimal你真的用对了吗？

目录

一、引子：看似简单的加法为何出错？

（一）10% + 20% = 0.3？计算器为何不讲理？

0.1 + 0.2 ≠ 0.3 的反直觉现实

（二）从“理所当然”到“错愕”的转变

二、误差之源：浮点数精度陷阱

（一）为什么 0.1 不能被精确表示？

类比：1/3 在十进制中无法精确表示

（二）Java 中的 double 是如何存储的？（IEEE 754 简介）

举个例子：double d = 0.1;

（三）几个典型的反直觉计算案例

✅ 案例 1：加法误差

✅ 案例 2：金额加法

✅ 案例 3：金额减法

（四）小误差，大问题：一分钱的损失如何变成 30 万？

📌 背景

📌 问题

📌 教训

小结：你眼中的“0.1”，计算机眼中可能是“0.10000000000000001”

三、第一道防线：BigDecimal 的正确使用

（一）BigDecimal 真能解决一切吗？

（二）new BigDecimal(double) 的巨大坑

📌 问题演示

📌 背后机制

📌 推荐做法

✅ 正确性对比

（三）推荐构造方式及其区别

（四）scale 和 precision 的影响及副作用（通过实际乘法案例分析）

✅ 基本概念

📌 真实案例：乘法未指定舍入模式时抛出异常

📌 另一种误用：精度丢失

（五）小结：BigDecimal 很强，但你得用对方法

四、第二道防线：浮点数的格式化与舍入

（一）String.format 为何得出奇怪的 3.4 和 3.3？

📌 原因剖析

📌 银行家舍入模式解释（HALF_EVEN）

（二）RoundingMode 的各种模式与默认行为

（三）DecimalFormat vs BigDecimal：谁才靠谱？

✅ DecimalFormat：适合展示层（String）

✅ BigDecimal：适合运算和持久化

✅ 实战建议

推荐格式化方式：BigDecimal + setScale + RoundingMode

（四）小结：展示不等于计算，格式不等于精度

五、判等陷阱：float/double/BigDecimal 的“==”误会

（一）为什么 amount1 - amount2 == 1.05 为 false？

📌 原因解析

⚠️ 危险的误判后果

（二）equals() 和 compareTo() 的区别

📌 为什么 equals 不安全？

✅ 推荐：使用 compareTo() == 0 判等

（三）浮点判等的三种思路（场景实用指南）

✅ 思路一：绝对误差阈值（适用于 double）

✅ 思路二：BigDecimal 精确判等（适用于金额）

✅ 思路三：compareTo == 0 判等

（四）实战踩坑示例：开发者 A 的误判之痛

（五）小结：判等，是浮点世界最后一道坑

六、总结与建议：写给开发者的避坑手册

（一）🧠 浮点数开发四步法：从思考到落地

1. 存储方式选对了吗？

2. 运算方式可靠了吗？

3. 格式化环节安全了吗？

4. 比较操作正确了吗？

（二）✅ 最佳实践 Checklist：金融系统浮点数安全用法

（三）📌 什么时候可以“不那么较真”？

（四）💡 技术背后的意识：你是在建一个“可信赖的系统”

（五）🎯 最后的金句总结（送给每一位开发者）

📘 全文回顾

干货分享，感谢您的阅读！

“就加了个 0.1 + 0.2，怎么就不是 0.3 了？”
“同一个接口，线上调账 1 分，结果整整少了 300,000 元？”

听上去像是段子，但这类事故在金融系统、支付平台、清结算逻辑中并不罕见。

在程序世界里，0.1 + 0.2 != 0.3 并不是一个 bug，而是数学与计算机底层的差异冲突。浮点数的本质、Java 中 double 的局限、BigDecimal 的使用误区、格式化的陷阱、判等的误解……这一切都可能让你写下看似完美的代码，却埋下金额出错的隐雷。

这篇文章，将带你逐步揭开