Java中精度丢失的根本原因是float/double的二进制表示缺陷，类型提升本身不丢精度，但会将精确整数拖入浮点误差体系；解决关键是在数据入口用BigDecimal("x.x")构造，全程调用add/subtract等方法运算，避免double字面量和==比较。
Java 数值计算中类型提升本身不会直接“导致”精度丢失，但它是精度问题暴露的关键环节——真正的问题根源是 float/double 的二进制表示缺陷，而类型提升（如 int → double、float → double）常把原本精确的整数拖入浮点误差体系，让隐性偏差浮出水面。排查重点不在“提升”动作本身，而在提升后是否继续用 float/double 做关键运算。
看清类型提升的真实行为
Java 的算术运算遵循“向更高精度类型对齐”规则：两个操作数中只要有一个是 double，另一个就自动转为 double；若只有 float，则转为 float；否则统一为 int。这个过程本身不丢精度（比如 int 123 → double 123.0 是精确的），但一旦参与运算的是本就无法精确表示的十进制小数（如 0.1），提升后反而固化了误差。
- ✅ 安全提升：int a = 100; double b = a; // b = 100.0，无精度损失
- ❌ 风险提升：float x = 0.1f; double y = x; // y 已是近似值 0.10000000149011612，提升只是复制误差
- ⚠️ 隐蔽陷阱：double z = 0.1 + 0.2; —— 这里 0.1 和 0.2 字面量默认是 double 类型，直接参与运算，提升未发生，但误差已产生
快速定位精度污染源头
不要只盯着最终结果，要逆向追踪：哪个变量/字面量最先引入了不可靠浮点值？常见高危点：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
小数常量直写：代码中出现
0.1、1.55、100.01等，除非明确用于非金融场景，否则默认就是 double 误差源 - 从 float 赋值或传参：方法接收 float 参数，内部转成 double 运算，原始 float 的误差被放大
-
Scanner 或 JSON 解析返回 double：用户输入 "19.99" 经
nextDouble()得到的是近似 double，不是精确 19.99 -
数据库字段映射为 double：MySQL 的
DOUBLE或 Oracle 的BINARY_DOUBLE读出后天然带误差
BigDecimal 正确介入时机
不是所有地方都该立刻 new BigDecimal，关键在“数据入口”和“业务临界点”：
立即学习“Java免费学习笔记（深入）”；
-
入口即转：用户输入、配置文件读取、JSON 解析得到的小数字符串，第一时间用
new BigDecimal("19.99")构造，绝不用new BigDecimal(19.99)（后者会把 double 误差带进来） -
中间运算全程 BigDecimal：加减乘除必须调用
add()、subtract()、multiply()、divide(scale, roundingMode)，避免混用 double -
输出前再转换：仅在需要展示或存入非精确字段时，才调用
toString()、doubleValue()（明确接受误差）或longValueExact()（校验是否为整数）
日常检查清单
写完计算逻辑后，花 30 秒扫一遍：
- 有没有
0.x类字面量？→ 改成"0.x"字符串传给 BigDecimal - 有没有
double price = config.getDouble("price");？→ 改用config.getString("price")再构造 BigDecimal - 有没有方法参数是
float或double？→ 检查调用方是否传入小数，考虑改为String或BigDecimal - 有没有
==比较两个 double？→ 改用Math.abs(a - b) 或 BigDecimal 的 <code>compareTo()
