Java中浮点数不是算错，而是IEEE 754二进制表示无法精确表达0.1等十进制小数，float（23位尾数）和double（52位尾数）均存在舍入误差，导致0.1f+0.2f≠0.3f、循环可能死锁、大数+1无效等现象；金融等场景须用BigDecimal或整数运算替代。
Java 中的浮点数（float 和 double）不是“算错了”，而是按 IEEE 754 标准用二进制科学计数法表示小数，天然无法精确表达多数十进制小数——比如 0.1、0.2、0.3。这不是 bug，是设计决定的底层机制。精度问题是否影响业务，取决于你对“相等”“累加”“存储一致性”的要求有多严格。
float 与 double 的精度差异和适用边界
float 占 32 位：1 位符号 + 8 位指数 + 23 位尾数（实际精度约 6～7 位有效数字）。它能精确表示的最大连续整数是 2²⁴ = 16777216；超过这个值，+1 可能无效（如 2324234234234234f + 1 == 原值）。
double 占 64 位：1 位符号 + 11 位指数 + 52 位尾数（精度约 15～16 位）。它能精确表示到 2⁵³ ≈ 9×10¹⁵，日常科学计算或中间结果处理基本够用，但依然无法解决 0.1 + 0.2 ≠ 0.3 的根本问题。
选择依据不是“哪个更准”，而是：
立即学习“Java免费学习笔记（深入）”；
- 内存敏感且误差可接受 → 用 float（如 OpenGL 坐标、传感器原始采样）
- 通用计算、日志调试、配置数值 → 默认用 double
- 涉及金额、ID、阈值判断、数据库字段 → 两者都禁用
精度丢失的典型表现与原因
所有异常现象都源于两个事实：十进制小数转二进制时无限循环（如 0.1 → 0.0001100110011…₂），以及尾数位数有限导致强制截断或舍入。
- 0.1f + 0.2f == 0.3f 返回 false：三者各自被截断为不同近似值，再相加也不等于第三个近似值
- for (float x = 0f; x != 1f; x += 0.1f) 可能死循环：每次累加引入微小误差，x 永远无法精确抵达 1.0
- 大数下相邻可表示值间隔变大：float 在 10⁷ 级别时，最小可分辨差值已大于 1，+1 不改变存储值
真正有效的精度控制方法
不靠“修复 float”，而靠选对工具和写法：
-
金融/账务/身份类场景：全程使用
BigDecimal，构造必须传字符串（new BigDecimal("0.1")），避免new BigDecimal(0.1)继承 double 的初始误差 - 金额类业务：直接用整数单位（如“分”代替“元”），加减乘除全走 long/int，展示时再除以 100.0 并格式化
-
需要比较 float/double：不用
==，改用Math.abs(a - b) < 1e-6（根据业务容忍度设阈值） -
循环步长控制：不用浮点递增，改用整数索引驱动：
for (int i = 0; i <= 10; i++) { float x = i * 0.1f; }
存储与日志中的实用建议
float/double 存数据库时，若字段类型为 FLOAT/DOUBLE，要清楚这是近似存储；若需精确还原，应存为 DECIMAL 或字符串。调试时别只看 System.out.println(f)，它做了自动舍入美化；想看真实值，用：
-
Float.toHexString(f)查十六进制表示 -
Double.doubleToRawLongBits(d)查原始位模式 - IDE 调试器中启用“show raw values”选项
不复杂但容易忽略。
