Java中float和double因遵循IEEE 754标准，无法精确表示0.1等十进制小数，导致舍入误差；金融计算、循环累加小步长等场景必须避免使用，应选用BigDecimal等类型。
Java 中的 float 和 double 本身无法做到“精确计算”——这不是 Java 的缺陷，而是它们遵循 IEEE 754 二进制浮点标准的必然结果。0.1、0.2、0.05 这类常见十进制小数，在二进制中是无限循环小数，必须截断存储，因此所有基于 float/double 的算术都自带舍入误差。所谓“精确”，只能靠选对类型和方法来逼近。
什么时候不能用 float/double 做“精确”计算
以下场景一旦用 float 或 double，结果注定不精确：
- 金融计算（如金额加减、利息结算）：0.01 + 0.02 ≠ 0.03，可能变成 0.030000000000000002
- 循环累加小步长（如 for (double x = 0; x
- 判断相等（if (d == 0.1)）：几乎总是 false，即使看起来“应该为 true”
- 需要固定小数位数输出（如显示“¥19.99”）：直接 toString() 可能输出 “19.989999999999998”
替代方案：用 BigDecimal 做真正十进制精确运算
当业务要求“数学上可预期的十进制精度”时，唯一可靠的选择是 BigDecimal：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 构造时优先用 String 构造器：new BigDecimal("0.1")，避免 new BigDecimal(0.1) —— 后者仍会先用 double 表示再转，误差已埋下
- 运算全部调用方法：add()、subtract()、multiply()、divide()（注意指定 scale 和 RoundingMode）
- 除法必须指定精度和舍入模式：divide(new BigDecimal("3"), 2, RoundingMode.HALF_UP)
- 比较用 compareTo()，不用 equals()（equals 会比较 scale，0.1 和 0.10 不等）
如果必须用 float/double，怎么“相对安全”地用
不是所有场景都需要绝对精确。在科学计算、图形渲染、传感器数据处理等允许误差的领域，可以接受 float/double，但需遵守规范：
立即学习“Java免费学习笔记（深入）”；
- 比较两个值是否“相等”：用 Math.abs(a - b)
- 避免链式小数累加：改用整数计数（如把元转为分，用 long 运算）再最后转回
- 格式化输出时用 DecimalFormat 或 String.format("%.2f", d)，但注意这只是显示四舍五入，不改变原始值
- 不要混用字面量精度：0.1f + 0.2f == 0.3f 可能为 true，但 0.1 + 0.2 == 0.3 几乎必为 false —— 因类型不同、舍入路径不同
float 和 double 之间怎么选
多数情况下直接选 double：
- Java 默认浮点字面量就是 double，省去写 f/F 的麻烦
- double 提供约 15–17 位有效数字，float 仅 6–7 位，差一个数量级
- 现代 JVM 和硬件对 double 运算优化充分，性能差距微乎其微
- 只在极端内存受限场景（如千万级 float 数组且精度要求低）才考虑 float
