java浮点数精度问题源于ieee 754标准下十进制小数无法精确表示为有限二进制，如0.1在二进制中无限循环，截断后产生固有误差；金融、订单、科学计算等场景必须用bigdecimal（字符串构造、指定舍入模式、compareto比较）或整数运算替代double。
Java浮点数精度问题不是bug，而是IEEE 754标准在二进制世界里表达十进制小数的必然代价。0.1 + 0.2 得到 0.30000000000000004，不是计算错了，是存储本身就“不准”。关键不在于回避它，而在于清楚什么时候能容忍、什么时候必须消灭它。
浮点数为什么存不准
double用64位按IEEE 754标准存数：1位符号 + 11位指数 + 52位尾数。问题出在十进制小数转二进制时——像0.1这样的数，在二进制里是无限循环小数（0.0001100110011…），只能截断保留52位。这个截断误差，从你写double d = 0.1那一刻起，就已经固化在变量里了。
后续所有运算都在这个带误差的值上进行，误差可能被放大，比如连续加10次0.1，结果是0.9999999999999999；也可能被掩盖，比如用DecimalFormat格式化成"0.10"，但底层还是那个不准的数，下次参与计算又暴露出来。
什么场景必须换掉double
以下情况不能靠“四舍五入显示”糊弄过去，必须切换数据类型：
- 金融计算：金额、利息、汇率、税费——一分钱都不能错
- 订单系统：价格、折扣、实付金额——涉及对账和审计
- 科学测量：仪器读数、实验数据——误差会直接影响结论
- 逻辑判断依赖精确值：比如
if (balance == 0.0)，哪怕差一个ulp（最小精度单位）也会跳过分支
BigDecimal正确用法避坑指南
用对了才叫高精度，用错了比double还危险：
- 构造必须用字符串：
new BigDecimal("0.1")，绝不用new BigDecimal(0.1)——后者直接把double的误差原样搬进来 - 除法必须指定精度和舍入模式：
a.divide(b, 2, RoundingMode.HALF_UP)，否则遇到1÷3这种无限小数会抛ArithmeticException - 比较必须用
compareTo()：bigA.compareTo(bigB) == 0，而不是equals()——后者会比较scale（小数位数），new BigDecimal("1.0").equals(new BigDecimal("1"))返回false - 避免无意义的链式调用：每次
add()multiply()都生成新对象，高频场景可考虑复用或预设scale减少开销
性能敏感场景的替代方案
BigDecimal虽准但慢，不是所有高精度需求都得扛它的开销：
- 货币类业务优先用整数：以“分”为单位存long，全程整型运算，最后除100转显示——零误差、零GC、最快
- 固定小数位计算可预设scale：如统一保留2位小数，初始化时就调用
setScale(2, RoundingMode.HALF_UP)，避免每次运算都重复设置 - Android或嵌入式环境慎用BigDecimal：考虑用Kotlin的
Money封装或轻量级定点数工具类 - 纯展示/非关键计算：用
Math.round(x * 100.0) / 100.0快速截断，或用String.format("%.2f", x)控制输出——只要不参与后续计算，够用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
