java数值类型精度损耗源于ieee 754二进制表达限制：0.1和0.2在二进制中无限循环，double尾数52位导致截断；float精确表示≤2²⁴整数，double≤2⁵³；long→float必丢精度（>2²⁴），long→double超2⁵³也丢精度。
Java 中数值类型转换的精度损耗，根源不在代码写法，而在于 IEEE 754 浮点数标准本身的二进制表达限制。0.1 + 0.2 ≠ 0.3 不是 bug，而是必然结果——因为 0.1 和 0.2 在二进制中本就是无限循环小数，必须被截断存储。
浮点数为什么存不准小数？
十进制小数转二进制靠“乘2取整”，但很多数无法有限终止：
- 0.1 → 0.0001100110011…（无限循环）
- 0.2 → 0.001100110011…（同样无限）
- double 类型尾数仅 52 位（+1 隐含位），超出部分直接舍去 → 存的已是近似值
float 和 double 的精度边界在哪？
精度不是“能保留几位小数”，而是“能精确表示多少个连续整数”：
- float：尾数 23 位 + 隐含 1 位 = 24 位精度 → 最多精确表示 2²⁴（约 1677 万）以内的整数
- double：尾数 52 位 + 隐含 1 位 = 53 位精度 → 最多精确表示 2⁵³（约 9 × 10¹⁵）以内的整数
- 超过该范围的 long 值转 double，低有效位会丢失（如 9007199254740993L == 9007199254740992.0）
哪些转换一定丢精度？
不是所有类型转换都安全。关键看目标类型能否容纳源值的全部有效位：
- long → float：32 位 float 只有 24 位有效精度，超过 2²⁴ 的 long 必丢低位
- long → double：虽为 64 位，但 double 尾数仅 53 位，long 超过 2⁵³ 时也会截断
- int → float：通常安全（int 最大 2³¹−1
- double → float：指数或尾数超限，直接四舍五入或溢出
怎么避免精度问题？
不靠“四舍五入显示”，而靠选对数据类型和运算方式：
- 金融计算用 BigDecimal：构造时用字符串（
new BigDecimal("0.1")），别用 double 字面量 - 比较浮点数用误差容忍：代替
a == b，写Math.abs(a - b) - 整数运算尽量保持整型：比如把元转成分，用 long 计算
- 调试时查真实值：用
Double.doubleToLongBits(x)看二进制存储，比打印更可靠
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
