java浮点数计算不精确是ieee 754二进制表示的固有缺陷，非bug；金融等高精度场景应使用bigdecimal（需字符串构造、指定舍入规则、用compareto比较）或整数放大法，科学计算等可接受误差的场景宜用误差阈值比较。
Java 中浮点数计算不精确，不是 bug，而是 IEEE 754 二进制表示与十进制小数之间固有的结构性矛盾。0.1 在二进制中是无限循环小数（0.0001100110011…），double 只有 52 位尾数，必须截断舍入——误差由此产生。金融、计费、科学建模等场景一旦忽略这点，轻则显示异常，重则资损。
BigDecimal 是高精度计算的首选方案
它用「整数 × 10⁻ˢᶜᵃˡᵉ」方式存储，完全避开二进制小数转换，支持任意精度和可控舍入。但用法不对，照样出错。
- 必须用字符串构造：new BigDecimal("0.1") ✅；new BigDecimal(0.1) ❌（0.1 本身已是 double 近似值，误差已带入）
- 除法必须指定 scale 和 RoundingMode：a.divide(b, 2, RoundingMode.HALF_UP) —— 不设会抛 ArithmeticException
- 所有运算返回新对象：BigDecimal 不可变，a.add(b) 不改变 a，需显式接收返回值
- 比较用 compareTo()，不用 equals()：equals() 会比较 scale（如 1.0 与 1.00 视为不等），compareTo() 只比数值大小
整数放大法适合高性能或嵌入式场景
把小数转为整数运算（如金额单位从“元”改为“分”），全程用 long/int，零误差、无对象开销、GC 压力小。
- 放大倍数要匹配业务精度：货币常用 ×100（分），利率计算可能需 ×10000（万分之一）
- 放大时务必用 Math.round()：(long) Math.round(value * scale)，避免 (long)(value * scale) 截断导致丢精度
- 注意溢出风险：long 最大值约 9×10¹⁸，若 scale=10⁶，原始值不能超 9×10¹² —— 超量级数据建议仍用 BigDecimal
浮点数比较和展示需分层处理
并非所有场景都需 BigDecimal。科学计算、传感器读数、图形坐标等对绝对精度要求不高，更看重性能和范围，此时应换思路。
- 比较用误差阈值：if (Math.abs(a - b)
- 展示用 DecimalFormat 或 String.format：仅控制输出格式，不解决计算误差。例如 System.out.printf("%.2f", 0.1 + 0.2) 显示 0.30，但内部仍是 0.30000000000000004
- 避免在 if 条件中直接写 == 比较两个 double：尤其是涉及循环累加或外部输入时，极易因微小误差跳过逻辑分支
底层存储原理决定你该何时放弃 float/double
float 占 32 位（1 符号 + 8 指数 + 23 尾数），能精确表示的整数上限约 2²⁴ ≈ 16777216；double 占 64 位（1+11+52），上限约 2⁵³ ≈ 9×10¹⁵。超出后相邻可表示数间隔变大，+1 可能等于原值。
- 比如 float f = 2324234234234234f; f == f + 1 返回 true —— 因为该数量级下最小可分辨差值已大于 1
- 连续累加 0.1 十次，sum 很可能 ≠ 1.0：每次加法都引入舍入误差，误差随次数累积放大
- 结论：只要业务语义要求“数学上严格相等”，就别碰 float/double 运算；否则，明确接受误差边界，并做对应防护
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
