java浮点数精度问题源于ieee 754二进制表示无法精确表达多数十进制小数，非bug而是设计约束；金融等关键场景必须用bigdecimal、整数单位法或误差阈值比较替代。
Java 中的浮点数（float 和 double）不是“算不准”，而是按 IEEE 754 标准用二进制科学计数法表示——这决定了它天然无法精确表达多数十进制小数，比如 0.1、0.2、0.3。这不是 bug，是设计约束。关键在于：什么时候能用，什么时候必须换方案。
浮点数精度丢失的底层原因
以 float 为例，它占 32 位：1 位符号 + 8 位指数 + 23 位尾数（实际精度 24 位）。这意味着它最多稳定保留 6～7 位有效数字。超出部分会被截断或舍入：
- 0.1 在二进制中是无限循环小数
0.0001100110011...，存入 float 时被强制截断，已失真 - 0.1f + 0.2f ≠ 0.3f，因为三个数各自存储时都带独立误差，相加后误差不抵消反而放大
- 大数值如
2324234234234234f + 1仍等于原值，因相邻可表示浮点数间距远大于 1
金融与关键业务场景必须避开 float/double
任何依赖“精确相等”或“零误差累积”的逻辑，都不该用原生浮点类型：
- 金额计算（如订单总价、分账比例）——0.1 元 + 0.2 元必须严格等于 0.3 元
- 身份编号、数据库主键、配置阈值判断（如
if (rate == 0.95)） - 会计对账、审计日志、合约结算等不可逆操作
这类场景一旦出错，后果是业务级的，不是技术调试能掩盖的。
推荐的三种实用替代方案
1. BigDecimal（首选，尤其金融）
构造必须用字符串：new BigDecimal("0.1")，而非 new BigDecimal(0.1)（后者传入时 double 已失真）；运算后建议显式设精度和舍入模式：
-
result.setScale(2, RoundingMode.HALF_EVEN)—— 银行家舍入，避免系统性偏差 - 除法务必指定精度和舍入：
a.divide(b, 4, RoundingMode.HALF_UP)
2. 整数单位法（高性能+确定性）
把小数转为整数运算，例如金额存“分”、距离存“毫米”、利率存“万分比”：
int centA = 10; int centB = 20; int sumCent = centA + centB; // 精确得 30 分- 展示时再转：
sumCent / 100.0或格式化输出 - 注意溢出风险：大数放大需用
Math.round(value * scale)，避免强制转型丢精度
3. 误差阈值比较（科学/图形/传感器类场景）
当只需“足够接近”，而非绝对相等时：
- 用
Math.abs(a - b) 替代 <code>a == b - 阈值按场景选：普通计算用
1e-10，物理引擎用1e-8，渲染坐标可用1e-6 - 循环累加避免用 float 步长：
for (int i = 0; i
日常开发中的避坑提醒
这些细节看似小，但高频踩坑：
- 日志里打印
float或double值，用Float.toHexString(f)或Double.toHexString(d)查真实二进制表示，比System.out.println更可信 - DTO/JSON 接口传浮点字段？优先约定用字符串格式（如
"amount": "19.99"），后端解析为BigDecimal - 数据库字段对应金额，类型必须是
DECIMAL(p,s)，不是FLOAT或DOUBLE - 单元测试验证精度逻辑时，别只看
assertEquals(expected, actual)，要用assertEquals(expected, actual, delta)或BigDecimal.compareTo()
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
