java浮点数精度问题非bug而是ieee 754标准在二进制硬件上的必然表现；0.1+0.2≠0.3因二者二进制无限循环被截断近似，运算后误差叠加；应避免==比较，改用容差或bigdecimal处理金融等需十进制精确场景。
Java 中的浮点数精度问题不是 bug，而是 IEEE 754 标准在二进制硬件上的必然表现。0.1 + 0.2 ≠ 0.3 的根本原因，是 0.1 和 0.2 在二进制中无法有限表达，存储时被截断成近似值，运算后误差叠加显现。要真正用好浮点数，必须理解其存储结构、误差边界和适用边界。
IEEE 754 浮点数如何存储小数
Java 的 float（32位）和 double（64位）严格遵循 IEEE 754 标准，将一个数拆解为三部分：
- 符号位（S）：1 位，0 表示正，1 表示负
- 指数位（E）：float 占 8 位（偏移量 127），double 占 11 位（偏移量 1023）
- 尾数位（M）：float 23 位，double 52 位；实际表示的是“1.M”这个归一化二进制小数
例如十进制 0.1 → 二进制无限循环小数 0.0001100110011… → 截断保留前 23 或 52 位 → 存入内存的已是近似值。这不是 Java 特有，而是所有基于 IEEE 754 的语言（C/Python/JS）共有的底层限制。
为什么 0.1 + 0.2 输出 0.30000000000000004
这个现象是三重近似叠加的结果：
- 0.1 被存为 double 近似值（真实值略小于 0.1）
- 0.2 同样被存为另一个 double 近似值（真实值略大于 0.2）
- 两者相加后，结果仍是一个 double 近似值，但因舍入规则，最终显示为 0.30000000000000004
可验证：System.out.println(0.1 + 0.2 == 0.3); // 输出 false。这不是计算错误，而是两个不同近似值的比较失败。
浮点数比较与误差容忍的正确写法
永远不要用 == 直接比较两个 float/double 变量。应使用带容差的绝对差值判断：
- 对一般业务场景，
Math.abs(a - b) 是安全阈值 - 对科学计算，需根据量级动态设容差，如
Math.abs(a - b) （ulp = unit in last place） - 注意：
Double.compare(a, b) == 0可用于排序或 Map 键比较，但不解决精度语义问题
何时该放弃 float/double，改用 BigDecimal
当业务逻辑要求“十进制精确性”时，必须切换：
- 金融计算：订单金额、税率、分账比例（哪怕 1 分钱误差也不允许）
- 配置参数：如数据库字段精度定义为 DECIMAL(10,2)，代码中也需保持一致语义
- 测试断言：验证算法输出是否等于某个精确十进制期望值
关键实践：
- 用字符串构造：
new BigDecimal("19.99")，而非new BigDecimal(19.99)（后者会先用 double 存 19.99 的近似值） - 除法必设精度与舍入模式：
amount.divide(divisor, 2, RoundingMode.HALF_UP) - 比较用
compareTo()，不用equals()（后者还比较 scale）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
