Java中double无法精确表示0.1，根本原因是0.1在二进制中为无限循环小数（0.000110011…₂），而IEEE 754双精度仅提供52位尾数，必须截断舍入，导致存储值为近似值，后续所有运算均在此误差基础上展开。
Java 中的 double 类型精度丢失，不是程序写错了，而是计算机用二进制表示十进制小数时“力不从心”造成的必然现象。它不只影响 0.1 + 0.2 ≠ 0.3 这种简单计算，更会在金融、计费、科学累加等场景引发隐蔽但严重的误差。
Double 为什么存不准 0.1？
根本原因在于：十进制小数 0.1 在二进制中是无限循环小数（就像十进制里 1÷3 = 0.333…），而 double 只有 52 位尾数空间，必须截断并四舍五入。这个近似值被存进内存后，所有后续运算都基于它展开，误差就此埋下。
- double 遵循 IEEE 754 标准：1 位符号 + 11 位指数 + 52 位尾数
- 能精确表示的十进制小数非常有限——仅那些分母是 2 的幂次的数，比如 0.5（1/2）、0.25（1/4）、0.125（1/8）
- 像 0.1、0.2、0.3、0.7 这类常见小数，全部无法精确存储
哪些操作会暴露精度问题？
不只是加减法，任何依赖浮点中间结果的逻辑都可能出错：
- 相等判断：if (a == b) 对 double 几乎总是不可靠，应改用 Math.abs(a - b) < 1e-10
- 循环控制：for (double x = 0.0; x < 1.0; x += 0.1) 可能多跑一次或少跑一次
- 金额累加：0.01 元反复加 100 次，结果可能不是 1.00 元，而是 0.9999999999999999
- 科学计算：大量小步长迭代（如数值积分）会让误差逐步放大
真正管用的解决方法
没有“万能方案”，关键看业务是否要求绝对精确：
立即学习“Java免费学习笔记（深入）”；
- 金额类场景（必须精确）：统一用整数单位（如“分”）存储，类型选 long；或直接使用 BigDecimal，构造时用字符串（new BigDecimal("0.1")），避免 double 构造器传入已失真的值
- 需要高精度但非金融：BigDecimal 同样适用，注意 setScale() 控制小数位与舍入模式（如 RoundingMode.HALF_UP）
- 允许误差的场景：图形渲染、传感器原始数据、机器学习权重——float/double 性能好且误差远小于噪声本身，可放心用
Double 存储原理一句话说清
double 把一个数拆成三部分存：符号位（正负）、指数（决定大小量级）、尾数（决定有效数字）。它本质是用二进制科学计数法表示数字，所以能表示极大极小的数，但牺牲了对多数十进制小数的精确表达能力——这不是 bug，是二进制与人类十进制习惯之间的天然鸿沟。
