应使用 bigdecimal 而非 float/double 处理金融金额，因后者基于 ieee 754 二进制浮点表示，无法精确存储十进制小数（如 0.1），导致初始误差及后续计算累积偏差，不满足金融场景零误差要求。
因为 float 和 double 的底层是二进制浮点表示（IEEE 754 标准），而日常金额如 0.1 元、0.05 元、19.99 元等十进制小数，在二进制中大多无法有限表达，只能近似存储——这不是 Java 的 bug，而是数学本质决定的必然现象。
十进制小数在二进制里根本存不准
比如 0.1：
它在二进制中是无限循环小数 0.0001100110011…₂，永远除不尽。
float（32 位）和 double（64 位）必须截断尾数，于是刚一创建就带上了初始误差。
你写 double x = 0.1;，内存中实际存的已经不是精确的 0.1，而是最接近它的二进制近似值。
误差会在加减乘除中快速累积
单次误差看似微小，但金融计算常涉及多次操作：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
-
0.1 + 0.2得到 0.30000000000000004，不等于0.3 -
1.00 − 9 × 0.10结果是 0.09999999999999998，少算 0.00000000000000002 元 - 循环扣减（如分次退款、分期还款）会让误差逐轮放大，最终余额可能变成
0.3999999999999999而非应得的0.40
精度指标不等于“小数点后几位安全”
float 约 7 位有效数字，double 约 16 位——但这指的是整个数字的有效位数，不是小数部分：
- 像
12345678.9这样的大额，已逼近 float 的整数精度上限（±16777216），再做小数运算极易失真 - 哪怕用 double，
12.35在内存中可能实际是12.34444444444444449，转成 BigDecimal 后四舍五入反而出错 - 数据库（如 MySQL 的 FLOAT/DOUBLE）同样存在存取不一致：插入
2.888888可能自动存为2.889
金融场景容不得“几乎正确”
银行账户、支付对账、发票开票、分润结算等所有环节，都要求结果确定、可复现、零偏差：
- 单笔误差仅 0.00000001 元，百万级交易后可能差出几百元
- 系统间比对时，
0.1f + 0.2f == 0.3f判断直接返回false - 这不是代码写得不好，而是 float/double 的设计目标本就不是精确十进制运算
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
