你有没有在写代码时遇到过这样的困惑：明明计算机那么聪明，为什么 0.1 + 0.2 得出的结果不是 0.3，而是一串长长的 0.30000000000000004？我第一次碰到的时候，还以为是自己代码写错了，反复检查了好几遍。后来才知道，这不是bug，而是计算机内部处理小数时的一个“天生缺陷”。今天我们就来彻底搞懂这个问题，并学会用正确的方法避开它。
1.1 亲手看看这个“不精确”
我用 Java 写一段最普通的代码，你可以在自己的电脑上跑一下：
public class FloatPrecisionDemo {
public static void main(String[] args) {
double a = 0.1;
double b = 0.2;
double sum = a + b; // 期望是0.3，但实际呢？
System.out.println("0.1 + 0.2 = " + sum);
// 再试试比较
if (sum == 0.3) {
System.out.println("它们相等！");
} else {
System.out.println("它们不相等，差值是 " + (sum - 0.3));
}
// 增加一个循环累加的例子
double total = 0.0;
for (int i = 0; i < 10; i++) {
total += 0.1; // 连续加10次0.1
}
System.out.println("0.1 加10次的结果 = " + total);
System.out.println("期望是 1.0，差值是 " + (total - 1.0));
}
}
运行结果会让你大吃一惊：0.1 + 0.2 = 0.30000000000000004，而且连续加10次0.1，居然得到 0.9999999999999999。这种误差在金融系统里可就是大问题了——如果算钱的时候少了一分钱，用户肯定不答应。
1.2 为什么会这样？——简单的二进制解释
计算机内部所有数据都用二进制存储，整数没问题，但小数就麻烦了。像 0.1 这样的十进制小数，换算成二进制会变成一个无限循环小数，就像十进制的 1/3 = 0.3333... 一样。而计算机的存储空间是有限的，比如 float 只有32位，double 只有64位，它只能截取一部分，于是就有了误差。
简单来说，计算机用“二进制科学记数法”来表示小数，即 IEEE 754 标准。这个标准把一个小数拆成三部分：符号位、指数位、尾数位。尾数部分用来存放有效数字，指数用来确定小数点位置。由于二进制无法精确表示某些十进制小数，存储时就会四舍五入，导致后面累加时误差越积越大。
比如 0.1 用二进制表示大概是 0.0001100110011001100110011001100110011001100110011001101...（无限循环），截断后就成了近似值。这就是一切不精确的根源。
二、生活中的影响
2.1 金融计算：钱不能有误差
金融行业对精度要求极高。你想想，用户存了1000元，年利率3%，每天计息一次，一年下来本该是1030.45元，但如果用 double 计算，可能因为浮点数误差变成1030.4499999元。银行存管系统里千千万万笔交易加在一起，误差会放大到不忍直视。所以金融软件绝对不能直接用 float 或 double 去做金额运算。
2.2 科学计算与游戏开发
科学计算里，如果结果只需要几位有效数字，用 double 完全没问题。比如物理模拟中，0.1的精度离真实值差0.00000000000000004，影响可以忽略不计。但在航天轨道计算等高精度场景，也需要特殊处理。游戏里位置坐标用 float 其实足够，因为像素级别的误差肉眼看不出来。
三、解决方案：BigDecimal
既然原生浮点数靠不住，Java 提供了一个“救星”——BigDecimal。它用十进制科学记数法，能任意精度地表示小数，代价是运算速度慢一些。
3.1 基本用法——正确构造和运算
import java.math.BigDecimal;
public class BigDecimalDemo {
public static void main(String[] args) {
// 注意：构造时传入字符串！如果传入double，误差会带到BigDecimal里
BigDecimal a = new BigDecimal("0.1");
BigDecimal b = new BigDecimal("0.2");
BigDecimal sum = a.add(b); // 加法
System.out.println("0.1 + 0.2 = " + sum); // 输出0.3，完美
// 减法、乘法、除法
BigDecimal x = new BigDecimal("10.5");
BigDecimal y = new BigDecimal("2.5");
BigDecimal diff = x.subtract(y);
BigDecimal product = x.multiply(y);
// 除法需要指定精度和舍入模式，否则可能除不尽
BigDecimal quotient = x.divide(y, 2, BigDecimal.ROUND_HALF_UP);
System.out.println("10.5 - 2.5 = " + diff);
System.out.println("10.5 * 2.5 = " + product);
System.out.println("10.5 / 2.5 (保留2位) = " + quotient);
// 比较：用 compareTo 而不是 equals（equals会考虑精度）
BigDecimal m = new BigDecimal("0.3");
BigDecimal n = new BigDecimal("0.30");
System.out.println("m.equals(n) = " + m.equals(n)); // false，因为精度不同
System.out.println("m.compareTo(n) = " + m.compareTo(n)); // 0，表示相等
}
}
注意：千万不要用 new BigDecimal(0.1) 这种构造方式，因为 0.1 这个 double 本身已经是不精确的，传到 BigDecimal 里只会把误差放大。一定要用字符串构造，或者使用 BigDecimal.valueOf(0.1)，后者内部会先转成字符串。
3.2 常见陷阱——绕开几个坑
除法不终结：比如 1 ÷ 3 = 0.3333...，如果你不指定精度和舍入模式，代码会抛出 ArithmeticException。所以除法必须写清保留几位小数以及舍入方式（比如向四舍五入 ROUND_HALF_UP）。
大量对象的创建：BigDecimal 是不可变对象，每次做加减乘除都会产生新对象，在循环里大量创建可能造成性能问题。解决方案是复用已有的 BigDecimal.ZERO、BigDecimal.ONE、BigDecimal.TEN 等常量。
比较时用 compareTo：equals 不但比较数值，还比较精度（scale），比如 2.0 和 2.00 在 equals 下不相等，但 compareTo 认为它们相等。通常业务上只关心数值，所以要用 compareTo。
3.3 其他注意事项
当与 double 交互时，使用 doubleValue() 或 toString() 转换；但注意 doubleValue() 会丢失精度。
有金额场景建议用 long 存最小单位（分），然后用 BigDecimal 做有精度的运算，最后再格式化显示。当然，直接用 BigDecimal 更灵活。
性能方面：一次运算大概比 double 慢几十倍，但对大多数业务系统，几百毫秒的延迟可以忽略。除非是做高频交易，否则用 BigDecimal 很安全。
四、应用场景分析
4.1 适合场景
金融、电商、计费系统：任何涉及金额、税、折扣等需要精确十进制计算的场景。
财务软件、报表、税率计算：小数点后需要精确到两位或更多位，且不允许误差累积。
科学分析中的高精度要求：如统计分析中保留很多位小数，但要注意性能取舍。
4.2 不适合场景
游戏物理引擎、实时渲染：对性能要求极高，精度需求低，用 float 更合适。
传感器数据、图形坐标：原始数据本身有物理误差，用 double 就足够。
大数据量数值计算：比如大规模矩阵运算，用 BigDecimal 会导致性能瓶颈，此时可以改用 float 或 double，并在最终结果处做适当舍入。
五、技术优缺点总结
先说说 double/float 的优点：天生速度极快，内存占用小，硬件直接支持，适合海量计算。缺点就是精度不稳定，某些十进制小数无法精确表示，且比较、累加容易产生微小误差。
再看 BigDecimal 的优点：能实现任意精度，完全消除了十进制小数的二进制表示问题，并且提供了丰富的舍入模式，非常适合商业计算。缺点是速度慢，对象占用内存大，不可变导致频繁 GC，而且使用时需要小心构造方式、除法陷阱等。
总的来说，如果你的运算结果需要“对人负责”（比如报表、账单、税务），请无脑用 BigDecimal；如果是“对机器负责”（比如物理模拟、特效渲染），用原生浮点就行。很多优秀编程规范就明确规定：所有货币计算必须用 BigDecimal。
六、注意事项
永远不要用构造函数传 double：new BigDecimal(0.1) 是自杀式写法。
比较时用 compareTo 代替 equals，除非你确需要比较精度。
除法一定要设精度和舍入模式，否则程序可能会崩。
格式化输出时注意小数位数：比如用 DecimalFormat 指定两位小数，避免显示过多尾数。
在与数据库交互时，对于金额字段，建议使用 DECIMAL 类型，Java 端对应 BigDecimal。
批处理或大数据集合里慎用：频繁创建 BigDecimal 对象可能导致内存抖动，可以考虑对象池或改用长整型后只在展示时转成 BigDecimal。
七、总结
浮点数精度问题看似很小，但背后藏着计算机科学的基本原理。其实不只是 0.1+0.2，任何用了 float/double 的地方都要留个心眼。而 BigDecimal 就像一把精准的尺子，让我们在需要精确计算的时候，能绕过二进制表示的天坑。理解它的构造陷阱、比较方式、除法要求，才能用得顺手。
希望这篇文章能帮你彻底告别“0.1+0.2=0.30000000000000004”的困扰。下次面试官问起，你也可以自信地给他解释二进制浮点数的秘密，顺便甩出 BigDecimal 这个完美解决方案。编程嘛，说到底就是和数据打交道——搞懂数据的脾气，代码才能写得顺心。