Java基本数据类型强制转换精度丢失的根本原因是底层二进制表示与截断规则，解决关键是确保转换可预期、可验证、可追溯：小数转整数用Math.round()而非(int)截断；大整数转小整数优先用Math.toXxxExact()校验；浮点运算避免double构造BigDecimal，应使用字符串或valueOf()；小整型运算遵循隐式提升规则，慎用装箱类型。
Java 基本数据类型强制转换导致精度丢失，根本原因不是“写错了代码”，而是对底层行为缺乏控制：截断小数位、丢弃高位字节、用二进制近似表示十进制数。避免的关键不是少用强转，而是让每次转换都可预期、可验证、可追溯。
小数转整数：别用 (int) 截断，用 Math.round() 四舍五入
直接写 (int) 3.9 得到 3，(int) -3.9 得到 -3 —— 这是向零截断，不是数学取整。正负数处理不一致，业务上容易出错。
- 统一用 Math.round()：它对正负数都按“四舍五入”规则处理（如
Math.round(-2.5)结果为 -2） - 注意返回类型：
Math.round(float)返回int，Math.round(double)返回long，赋值前需匹配目标类型 - 若需保留小数位参与后续计算（如金额保留两位），应跳过整数转换，直接用 BigDecimal 处理
大整数转小整数：加校验，别信“值看起来不大”
像 int → byte、long → int 这类转换，JVM 不检查范围，只取低 N 位重新解释。1500 强转成 byte 得到 -56，不是因为“算错了”，而是 1500 的低 8 位补码就是 -56。
- 优先使用 JDK 提供的安全方法：
Math.toIntExact(long)、Math.toByteExact(int)，超范围直接抛ArithmeticException，暴露问题而非掩盖 - 手动校验示例：
if (x >= Byte.MIN_VALUE && x - 若需溢出时取边界值（如超了就设为 127 或 -128），可用 Guava 的
Ints.saturatedCast()
浮点数参与的运算：绕开 double 初始化 BigDecimal
精度丢失最典型的场景是金融计算：new BigDecimal(19.99) 看似干净，实则 19.99 已被 double 存为近似值（如 19.990000000000002），BigDecimal 只是把它“精确地记下来”。
立即学习“Java免费学习笔记（深入）”；
- ✅ 正确构造：
new BigDecimal("19.99")或BigDecimal.valueOf(19.99)（后者内部转字符串，更安全） - ❌ 禁止构造：
new BigDecimal(19.99)—— 无论数值多规整，double 底层已失真 - 数据库读写必须直连 DECIMAL 字段：
rs.getBigDecimal("price")，禁用rs.getDouble()再转
整数运算中隐式提升：别让 byte/short 拖慢又易错
两个 byte 相加，结果一定是 int；short s = 10; s = s + 1; 编译失败——因为 1 是 int，默认提升规则强制所有小整型参与运算时先升为 int。
- 高频计算（如图像处理）中，用
int[]替代byte[]，配合注释说明值域（如 “仅存 0–255”），比反复强转更高效、更清晰 - 状态码、ID 等语义明确的值，直接用
int或long，不用byte省空间——JVM 对基本类型操作始终按 int 或更宽类型执行，无实际内存优势 - 循环内避免
Integer sum = 0; sum += i;，改用原始类型long sum，避开装箱拆箱和潜在空指针
